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CHAPTER 1 
Introduction 


1.1 Motivation 

The contents of this paper and the associated software came about as a di- 
rect result of certain needs for the Center for Intelligent Robotic Systems for Space 
Exploration (CIRSSE) dual arm robotic testbed at Rensselaer. Relatively indepen- 
dent research groups have been working on various subsystems of a robotic platform 
capable of supervised autonomy. Each of these subsystems have matured to the 
point that significant effort is now going into the integration of the components 
for high level testing and development. To successfully integrate the testbed, tools 
were required to 1) model the system; 2) integrate the subsystems; emd 3) obtain 
user interaction. This paper presents a Petri net based controller which satisfies 
these three needs. An underlying theme in each of these requirements is flexibility, 
such that future expansion and development of the system will not render today’s 
controller obsolete. 

1.2 The CIRSSE Dual Arm Robotic Testbed 

The architecture of the CIRSSE dual arm robotic testbed was developed to 
provide a platform for research and development of a space-based robotic system 
[9] [26]. The hardware consists of two PUMA manipulators connected to carts on a 
common linear track, with a laser and five camera vision system. The manipulator 
hardware is shown in Figure 1.1. Software servicers have been developed to perform 
the low level interactions with the hardware, providing a level of abstraction for 
simplified application development. This testbed is currently supporting a num- 
ber of research projects, including: visual object recognition; visual servoing; strut 
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and node assembly and disassembly; two arm coordination and control; and path 
planning with collision avoidance. 

1*3 Thesis Organization 

Chapter I presents the motivation behind this thesis, emd briefly discusses the 
CIRSSE testbed. Chapter 2 provides a brief description of current Petri net theory, 
tools and controllers. Chapter 3 presents the problem description, as well as the 
proposed implementation of the solution. Chapter 4 details the use of the controller 
itself, both in setting up and actually running the software. Chapter 5 discusses the 
controller’s conformity to Petri net theory. Chapter 6 presents two case studies in 
the CIRSSE testbed environment. Chapter 7 summarizes the results of this project, 
and provides directions for future work. Appendix A contains the descriptions of 
the currently available enabling and post functions. The software for this controller 
implementation is contained in the remaining appendices. Appendix B contains the 
header files. Appendix C contains the source code for the player task, and Appendix 
D contains the source code for the display task. 


CHAPTER 2 

CURRENT PETRI NET THEORY AND APPLICATIONS 


2.1 Introduction 

This chapter describes several aspects of Petri net theory relevant to this 
project. Current tools aiding the design and analysis of Petri nets cue discussed, 
and two existing Petri net controllers are presented. 

2.2 Petri Net Theory 

Petri nets are a graphical and mathematical modeling tool for discrete event 
dynamic systems [12] [14]. They are particularly well suited to modeling asyn- 
chronous, synchronous, and concurrent actions, which occur extensively in most 
large robotics and automation applications [1] [15]. One representation of a Petri 
net is a weighted bipartite directed multigraph, whose node types are called tran- 
sitions eind places. Places and transitions are interconnected by arcs, termed input 
arcs and output arcs with respect to the connected transition. Each place may con- 
tain some non-negative quantity of tokens, and this marking indicates the state of 
the system. The firing of a transition represents an event that changes the state of 
the system, thereby chainging the marking of the places. A Generalized Stochastic 
Petri Net (GSPN) is an ordinary Petri net whose transitions may take a determin- 
istic period of time to fire. A transition is enabled to fire when each of its input 
places contain at least cis many tokens as the weight of its associated input arc. An 
enabled transition may fire at any time, and that firing consists of three phases: 
1) the enabling tokens are removed from the input places; 2) some action may be 
performed which may cause a time delay; and 3) once the action is complete, tokens 
are added to the output places. 
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A Petri Net Transducer (PNT) [22] [24] is an extension of a GSPN which adds 
another enabling condition to the firing requirements of a transition. An input tape 
composed of members of the input alphabet is p 2 issed to the PNT, whose transitions 
possess 2 in optional tape requirement. A transition with a tape requirement will be 
enabled only if the head of the tape contains the proper command and its token 
requirements are met. These extensions make PNT’s a more powerful modeling 
tool, but it does make the analysis of the Petri net more complicated. 



Figure 2.1: An Example Petri Net Transducer 

An example PNT is shown in Figure 2.1. The two initial transitions each 
require a different tape commauid in order to fire. If Parallel is at the head of the 
tape, the upper path will be taken, while if Sequential is at the head the lower 
path will be followed. Both paths perform two actions, but the upper path performs 
Actionl and Action2 concurrently, while the lower path performs Acti''n3 and 
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Action4 sequentially. 

2.3 Petri Net Tools 

Although Petri nets have been used extensively in manufacturing environ- 
ments, to date there is no one package that provides full design and analysis capa- 
bilities. Petri nets are inherently graphical, emd lend themselves nicely to Computer 
Aided Design entry. However, the analysis capability of the existing tools seems to 
be inversely proportioned to their ease of use and quality of interface. 

2.3.1 GreatSPN 

GreatSPN [3] offers a graphical user interface for the construction, editing and 
^Lnalysis of Petri nets. This package was developed at the University of Torino, 
Italy, as a tool for the specification and performance anadysis of computer systems, 
and has since evolved into a general Petri net tool. GreatSPN supports immediate, 
stochastic and timed transitions, as well as inhibitor arcs. The Petri net can be 
analyzed for basic, properties, such as p and t invariants, boundedness, steady state 
token distribution, and deadlock. Performance can be determined as well in terms 
of token throughput. In addition to the screen display, the software can adso save 
the net in a postscript file for printing hardcopy output. 

Note that GreatSPN is not without drawbacks. Its analysis capabilities zire 
not fully implemented yet, and the abilities of the existing analysis options degrade 
with larger Petri nets. Finally, although the graphical user interface represents an 
advance over typical text based approaches, some aspects of the interface are still 
awkward to use. 



2.3.2 SPNP 


SPNP [4] is a text based Petri net analysis package developed at Duke Univer- 
sity that provides a wide variety of analysis capabilities. The Petri net is described 
as a series of C function calls, which also define the type of analysis desired. SPNP 
builds the reachability graph, and from this it can determine the steady-state Markov 
chain, token distributions and throughput, and a host of other parameters. 

Although the SPNP software itself can analyze a vary large net, entering the 
C function calls is error prone and difficult to verify. One approach to this problem 
is to use a graphically oriented design program, and convert the stored informettion 
into the desired format. GreatSPN2SPNP [13], written at Rensselaer Polytechnic 
Institute, is a conversion program that translates a GreatSPN output file into a 
suitable SPNP input file. 

2.3.3 ^CpQ 

Xpn [8] is a Petri net design tool being developed at Rensselaer Polytechnic 
Institute featuring a full graphical user interface running under X-\vindows. The 
created Petri nets may be stored in a variety of formats, suitable for use with other 
packages such as GreatSPN, SPNP, as well as the controller presented in this thesis. 
Note, however, that Xpn offers no analysis capability and is solely used for the net 
design. Currently, this package is under development, and does not yet fully support 
all file formats. 

2.4 Petri Net Controllers 

Petri nets have been used in industry for the modeling of systems, and many 
dedicated controllers have been developed with the aid of those models. Recent work 
at CIRSSE has been geared towards developing general Petri net controllers, for use 
in distributed hierarchical systems. Two such controllers developed at CIRSSE were 
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submitted as Masters Projects in 1991. Although both controllers were designed to 
solve the same general problem, they possess very different implementations. These 
two, along with a manufacturing implementation, are described below to highlight 
their differences and to provide a basis of evaluation for the controller presented in 
this thesis. 

2.4.1 Petri Net Controller 

The Petri Net Controller (PNC) [5] [16] was developed to ease the difficulty in 
organizing and controlling manufacturing stations. It was one of the first implemen- 
tations to abstract itself from a direct hardware interface, «md instead e.x:ecuted on 
a general purpose computer. The capabilities of PNC are based within the places 
of the Petri net, where different types of places are used to represent and perform 
different actions. Macro places represent an embedded subnet, action places interact 
with the external world, and several other types exist as well. 

Although a hierarchical arrangement of Petri nets is possible through the use 
of macro places, this organization is still executed on only a single computer. There 
are no built in means of distributing the controller itself over multiple machines. 
Additionally, the macro places allow for only one entry point to a particular sub- 
net, which limits flexibility. Finally, the execution algorithm as implemented does 
not preserve the Petri net property of fairness, and special c«ire must be made in 
designing each Petri net. 

2.4.2 TokenPasser 

TokenPasser [11] was designed to allow for the rapid prototyping of a dis- 
tributed hierarchical control system which utilizes Colored Petri Net Transducers. 
Individual Petri nets, each with their own display, can be distributed on different 
computers. Each transition can execute a function call whenever it is fired, allowing 
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for basic controller operation. The implementation of TokenPasser does not lend 
itself to use as a full fledged controller. However, it does provide performance data 
through simulation, which can be extremely useful in determining communication 
delays between various configurations. Designing a new Petri net application re- 
quires that the user write a series of C function calls to be compiled 2 Uid linked with 
the controller software which define and initialize the net structure. 

2.4.3 DPNC 

Distributed Petri Net Controller (DPNC) (2] is a fuller controller impilemen- 
tation for distributed systems than TokenPasser, designed with control as a main 
objective, as opposed to simulation. A series of players are connected in a token ring 
fashion, with one centred display. This controller executes a single Petri net, with 
individual sections being executed on the separate players. DPNC uses GreatSPN 
to design the Petri net, and the resulting definition file is converted into C functions 
by a UNIX script. These C functions are compiled and linked with the controller 
code itself, as is the case with TokenPasser. Additionedly, zmy function calls that 
are associated with the firing of a transition must be written, compiled and linked 
as well. The single display is both a blessing and a curse. The user need only 
concern himself with one window on the screen, and all action occurs in this one 
location. However, the Petri net for any real controller will be far too large to fit 
on a single screen, and any attempt to do so will result in a cluttered and confusing 
representation. Like PNC, this controller does not preserve the Petri net property 
of fairness, and requires careful Petri net design. 

2.5 Summary 

Petri nets are a powerful tool for the modeling and analysis of discrete event 
dynamic systems. A Petri net based controller, with a fixed embedded Petri net 
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or some more flexible arrangement capable of using an arbitrary Petri net, can be 
designed, analyzed and verified before the actual implementation. Additionally, any 
desired modifications to the controller can be evaluated before implementation as 
well. Tools such as GreatSPN may be used to graphically design and modify the 
Petri nets, while other tools such as SPNP can be used for detailed analysis. 

To date, only PNC has been used in conjunction with physical hardware. 
It was used to control a machining workstation based on a Cincinatti Milacron 
SVC Machining Center, which produced a variety of parts. The other controllers, 
TokenPasser and DPNC, were not developed sufficiently to be used in a real system. 
However, with additional work and effort they would have resulted in a more flexible 
means of controlling and monitoring a distributed, hierarchical system. 



CHAPTER 3 

PROBLEM STATEMENT AND SOLUTION 


3.1 Introduction 

This chapter details the requirements for the Petri Net controller, 2uid discusses 
the chosen implementation. This controller supports a distributed, heterogeneous, 
hierarchical system with flexible execution and display options. 

3.2 Project Specification 

The requirements for this project are geared towards a general Petri net con- 
troller, and are not specific to its initial application, i.e., the CIRSSE testbed. First 
of all, it must support a distributed system. It is assumed that the application 
can execute on multiple processors, not necessarily in the Scime machine or even 
location. Note that the term distributed not only applies to the hardware in the 
system, but to the actual controller components as well. The overall system may 
be heterogeneous, in the sense that the individual computers may be running dif- 
ferent operating systems or even vary in architecture. The controller must allow 
for hierarchical interconnections between the individual Petri nets, as a large class 
of systems are ideally controlled with this configuration. Graphical displays must 
be able to represent the actual executing Petri net, as well as subsets of places and 
transitions to provide a summary of the entire application. Finally, the development 
of a new application should not require the recompilation of the controller itself, i.e., 
its configuration should be data driven. 
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3.3 Project Design 

The controller is broken into two distinct classes of processes: players and 
displays. The players are responsible for executing the Petri nets which actually 
perform the control of the system. As tokens flow through the net, the player 
performs any necessary interactions with other players and the external world. The 
displays are responsible for presenting the state of the system to the user, and 
provide some means of controlling the players. It is extremely important to recognize 
that the players and displays are completely separate entities, and that the players 
can execute even in the complete absence of the display processes. However, most 
applications will include the displays as a means of monitoring and controlling the 
execution of the players. To this end, the display contents are highly configurable 
to aid in the meaningful representation of the underlying player Petri nets. 

3.3.1 Petri Net Transducer Extensions 

The concept of PNTs is extended for this application, providing for a more 
efficient and powerful means of actually controlling a system. This extension is 
made in the form of an additional enabling requirement, called an enabling function. 
This enabling function returns a Boolean value indicating the state of an external 
condition. Although this extension can modeled by eidding an additional place 
plus inhibitor arcs to the Petri net for each possible tape command, it is not readily 
implemented as such. A second extension is the inclusion of post functions, which are 
executed with the firing of transitions. These post functions are the main mechanism 
of performing an external action. These extensions axe shown in Figure 3.1, where 
the enabling condition of the transition consists of token requirements, am enabling 
function, and a tape command. The firing of the transition causes the post function 
to be executed. 
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Tape Command 
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Figure 3.1; The Extended Petri Net Transducer 

3.3.2 CmSSE Testbed Operating System 

The CIRSSE Testbed Operating System (CTOS) [6] [9] [26] was developed to 
facilitate the execution of applications which consist of multiple tasks emd require 
intertask or interprocessor communication. CTOS greatly simplihes design of a 
distributed application, and forms the infrastructure for development on the CIRSSE 
testbed. CTOS is an extension of the base operating systems at CIRSSE, and has 
been implemented for both UNIX and VxWorks. 

CTOS offers an environment for conveniently distributing tasks ajid executing 
a distributed application. A distributed application can be started with a single 
command line, through the use of configuration files. These application configura- 
tion files contain the list of tasks to be loaded and what machines to run them on, 
as well as any initial parameters to pass to the individual tasks. Reconfiguring an 
application involves simply editing this file, and rerunning the application. No other 
parameters need be changed. 
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Each task is assigned a symbolic name in the application conh:^uration fUe, 
and it is this name that other tasks use to perform interprocess communication. If 
one task wishes to communicate with another, it first queries CTOS for the task id 
corresponding to the symbolic name of the other task. The task then uses CTOS 
message passing routines to perform the communication, where the task id is used 
to identify the recipient of the message. 

Programs to be executed as CTOS tasks must be designed to exist in an event 
driven environment. These CTOS tasks are often called event handlers, due to 
their interna! construction and external interface. In general, an event handler task 
is asleep until it receives a message indicating that there is some work for it to 
perform. The event handler is wakened, and performs the appropriate actions. It 
then puts itself back to sleep. 

3.3.3 The Data Object Manager 

One major concern of any distributed system is the location and accessibility 
of data objects. A Data Object Manager (DOM) [9] has been developed at CIRSSE 
to solve m 2 uiy data storage issues and provide a consistent interface to manipulating 
those objects. Any CTOS task can access the DOM, which offers a variety of 
capabilities. Data objects can be created, modified, renamed, deleted, copied and 
more. Oftentimes the existence of a particular data object is represented as a place 
in a Petri net; this place serves as a precondition for the firing of a transition which 
performs some action involving that object. 

3.3.4 Player Design 

The player task is responsible for the execution of the Petri net that actually 
controls the system. This involves the selection and firing of individual transitions, 
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and interfacing with the tasks that perform actions. Another significant responsi- 
bility is notifying all interested display tasks of changes in the state of the Petri net. 
Figure 3.2 shows a high level view of the operation of the player code. 

The player code .spends the majority of its time in the Petri net execution 
phase. While there are no messages pending, the player is attempting to fire tran- 
sitions. There are two execution modes, continuous and single-step. In continuous 
mode, the player repeatedly examines the enabling status of all transitions, and 
fires those that are enabled. In single-step mode, the player repeatedly examines 
the enabling status of those transitions which are not displayed in any display, and 
individually examines those transitions which are clicked on in the display. As soon 
as a message is received, the player exits from this enabling checking mode, ^md 
processes all of the pending messages. Once there are no more pending messages, 
it reenters the enabling checkin;^ mode. These messages include the arrival of to- 
kens from other players, the tog > ing of player modes, and veuious CTOS commands 
such as application exit. The single-step mode is especially useful for debugging or 
user control of t^ system. Note that each player can be in either continuous or 
single-step regardless of the modes in the other players. 

Petri net theory states that the firing of an enabled transition should occur 
without regard to the other transitions in the Petri net. There should be no partic- 
ular order in which the transitions are examined for possible firing, or the execution 
of the Petri net may not follow the behavior predicted by the model. Therefore, 
in terms of theory an ideal implementation woo Id randomly select which transition 
to examine as it executed the Petri net. However, a controller is also concerned 
with speed, and m a sizable net with a small number of enabled transitions, a pure 
random selection can result in an undesirable delay. A hybrid random- linear ap- 
proach was taken. A random transition is selected to examine. If it is enabled, it is 
fired. Otherwise, the tran;>itions are e.xamined in order until an enabled transition 
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is found and fired. After the transition is fired, the process begins again with the 
random selection. This provides for an arbitrary firing sequence, w’hile maintaining 
real world performance. 

3.3.5 Display Design 

The display task provides the user with a graphical representation of the status 
of the system. These displays are highly configurable, and can serve a wide variety 
of purposes. They do not need to mirror the underlying player Petri net, and can 
be used to provide a simplified representation of a particular net, or even a global 
representation of the entire collection of nets. Figure 3.3 shows a high level view of 
the operation of the display code. The parallel e.xecution blocks in the flow indicate 
where a monitoring task is spawned. This spawned task sits in a loop monitoring 
the display window for user input and other X-window events. Whenever an event 
occurs that is of importance to the display event handler, a message is sent. The 
event handler then taJces whatever action is appropriate. The display also receives 
messages from the various player tasks, indicating that some aspect of the Petri net 
status has changed. These can include tokens being removed or added to a place, 
or transitions beginning or ending to fire. Transitions in the display cam correspond 
to two transitions in the player tasks, the firing of one causes the transition in the 
display to be highlighted, while the firing of the other completes some action and 
unhighlights the display transition. 

3.3.6 Function Execution 

One of the most important features of a controller is the ability to interact with 
the external world. W'ithout this ability, the controller is reduced to a simulator. 
Due to this importance, an e.xtremely flexible and powerful mechanism had to be 
developed to handle this interaction. 
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Figure 3,3; Display Code Flow 
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The controller supports enabling functions and post functions. Each of these 
is split into two classes, local or remote. The loced functions are those that are 
compiled into the controller itself, while remote functions are those that are executed 
by a separate task. The local functions are geared towards looping or checking the 
status of some variable in the DOM. The external functions perform actions such as 
moving a robot, taking a stereo picture, etc. When a remote function needs to be 
executed, the player sends a message lo the task capable of performing the operation, 
informing it of which particular action is requested and what data objects to use. 
The task name, action, and data objects are specified in the player configuration 
file. 

3.3.7 Tape Issues 

This controller fully supports the concept of a PNT input tape. Transitions 
can possess an optional tape command, which is an additional enabling requirement. 
These tape requirements can be used to parse a high-level language into lower level 
components, aiding in the decomposition of tasks. Although the player itself can 
accept an input tape and process its contents, no CTOS task exists for actually 
sending a tape to the player. As stated ewlier, the tape commands can be imple- 
mented as a group of input piaces, and current Petri net designs in this thesis are 
utilizing that approach. 

3.4 Summary 

The controller has been designed to meet adl of the current requirements of 
the CIRSSE dual arm robotic testbed, and in fact exceeds them in order to provide 
a viable system for future applications and research. 


CHAPTER 4 

USING THE CONTROLLER 


4.1 Introduction 

This chapter provides a brief user manual for designing and implementing an 
application utilizing this controller. Design concepts, as well as technical details con- 
cerning the related configuration files are presented and discussed. The commands 
available through the displays at runtime are also described. 

4.2 Application Design Methodology 

A typical application consists of three to five player tasks, and approximately 
the same number of display tasks. The primary work is performed in defining the 
player Petri nets and their interconnections. The display Petri nets are more often 
than not a stripped down version of the player Petri nets, with such structures as 
buffers or communication points omitted for clarity in the display. 

The player Petri nets cire interconnected via local and remote places. A local 
place is defined as a place that is native to the player Petri net in question, while a 
remote place is one which is native to some other player. This is best demonstrated 
with an example. Figure 4.1 shows three player Petri nets. 

The first is a global net which performs two distinct actions. This net can be 
broken into two subnets, shown at the bottom. Note that the place in_progress 
appears in both subnets. The distinction is that in.progress is local to subnet 2, 
and remote to subnet 1. A remote place in a net does not exist as a regular place, 
but is actually a Unk to the local place in the remote net. The remote net can be on 
the same processor, a different processor within a single VME cage, or even across 
the ethernet network, and the link provides the interconnection to that Petri net. 
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Ready Li4>rogreu Done 



AcUool aocal) 

Figure 4.1; Petri Net Interconnection 


The controller itself does not enforce the use of any particular interconnection 
scheme, however, one should be adopted if the analysis of the Petri net is desired. 
The two case studies presented at the end of this paper are organized in a hier- 
archical fashion, and a requirement for both is the ability to emalyze the system 
and provide a consistent interface between modules. A consistent interconnection 
strategy provides two benefits: only one method of analysis needs to be established 
for the system as a whole; and the designers of new Petri nets in the system have 
a template for interconnection to follow. A hierarchical organization usually fol- 
lows the principle of Increasing Precision with Decreasing Intelligence [17] [19]. The 
highest intelligence and global responsibility resides in the top of the tree, while 
the lowest level functional abilities lie along the bottom. Levels inbetween serve 
as coordinators, taking the higher level instructions and breaking them into a form 
usable by the lower level. This corresponds to a situation where we would like a 
single transition in a higher Petri net to request that a lower Petri net perform some 
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action for it. The concept of this structure is shown in Figure 4.2, where the high 
level functions Actionl and Action2 correspond to the indicated subnets. 


Ready ^.progress Done 



Figure 4.2: A Petri Net Hierarchy 

Petri nets to be used in the CIRSSE testbed use a formal coordination struc- 
ture to provide this functionality. Each level in the Petri net hierarchy can only 
perform a single action at a time for the level above it. This does not mean that 
parallelism cannot occur within each Petri net, only that a net can only satisfy one 
request at a time from the higher levels. This coordination structure is shown in 
Figure 4.3, detailing the necessary components in both Petri nets. The single tran- 
sitions in Figure 4.2 have been replaced with two transitions and a place. The place 
is used to indicate that the requested operation is in progress. When the Petri net is 
available, the places avail and S have tokens in them. S is a semaphore indicating 
whether the net is currently performing some action. If not, begin can fire, placing 
a token in in.progress and I. It adso places a token into one of the request action 
places, which indicates which operation is to be performed. This example Petri net 
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can perform three possible actions, whose request arcs are shown as dotted lines. 
Only one of these arcs should actuaUy e.cist for n given begin transition. The tran- 
sition start can now fire, putting a token in ready. Now the first transition of the 
requested action may be fired. Once the operation is complete, a token is put in 
place done. The transition finish is then enabled, and upon firing puts a token 
in place O. This enables transition end to fire, which restores the semaphore and 
allows the Petri net to process another operation request. 



Figure 4.3: The Coordination Structure 
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4.3 Application Configuration File 

The entire controller application consists of CTOS tasks, which are executed 
through the aid of a CTOS application configuration file. This file details the dis- 
tribution of tasks, their symbolic names for interprocess communication, and any 
initial parameters required by the individued tasks. 

The individual tasks may be executed on any machine in the network, so long 
as it is running CTOS. Prior to declaring which tasks to run, the machine to load 
them on must be defined. This is done with the line: 

chassis machine .name 

This indicates that the tasks after this line aire to be started on the machine specified 
by machine_name. Multiple chassis fines may be placed in the file in order to 
distribute the tasks over the various machines. 

The player task accepts only one parameter, which indicates which configura- 
tion file to use. Here are the lines corresponding to a player task and its parameter: 

task play.eh ..playerl 
args playerl netl 

The keyword task indicates that this line defines a symbolic name for a task to be 
executed. The CTOS task play.eh is the player program, and in this example it 
is referenced by the symbolic name playerl. The keyword args indicates that the 
line defines a parameter to be passed to a task. In this instance, the string netl is 
passed to the task with the symbolic name playerl. 

The display taisk can accept two parameters, one indicating which configu- 
ration file to use and one indicating which monitor to display on. Here are the 
lines: 

task disp.eh displayl 
args displayl netl xterm6:0.0 
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Here the CTOS task disp_eh is the display program, and it is referenced by the 
symbolic name display 1. The two parameters are passed using the same args iine. 
The first parameter is the configuration file to use, and it is required. The second 
line is the actual display device to use. If the display device is omitted, the window 
will appear on the user’s default device. 

4.4 Petri Net Configuration Files 

The Petri net configuration file is the mechanism used to provide the player 
and display tasks with the configuration and task interconnections of the Petri net 
that they are to execute or display. The configuration files differ in content between 
the player and display tasks, but their format is similar. In an effort to use existing 
tools for the design and analysis of a distributed system, it is recommended that the 
Petri nets be designed using GreatSPN, or another program such as Xpn that can 
generate the GreatSPN file format or this configuration file format directly. The 
configuration file begins with the GreatSPN .net file, emd additional configuration 
data for each place and transition is appended to the end. This approach W 2 is 
taken to allow the user to modify this additional data with a standard editor until a 
customized design tool such as Xpn is fuUy developed and available. The file naming 
convention used by this controller is that all player configuration files end in .pnet 
and that all display configuration files end in .disp. 

4.4.1 Player File 

The player configuration file provides the details of the executable net. It is in 
this file that we specify the tape commands, enabling functions, and post functions 
for each transition. We also specify the owner task of every place referenced by a 
transition in this net. 
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The configuration data begins with the line: 

SUBNET task.name 

This identifies the file as a player configuration file, and provides the symbolic name 
of the task for reference. Following this header, there is a line for every place and 
transition in the Petri net. The format for a place consists of: 

PLACE local_name [LOCAL] I [REMOTE remote.name remote.ovner] 

A place with the LOCAL keyword is owned by this Petri net, and it is referenced 
by all other tasks as local-name. A place with the REMOTE keyword is owned by a 
different Petri net, and corresponds to the place named remotejiame in the player 
with the symbolic name remote..owner. Here is the format for a transition: 

TRANS local.name [TAPE command] 

[[ENABLE. LOCAL function.name action data.name] 

I [ENABLE.REMOTE task.name action data.objects]] 
[[PQST.LOCAL function.name action data.name] 

I [PCST.REMOTE task.name action data.objects]] 

Transitions aie always owned by the player that they appear in, and 2ire not ref- 
erenced by any other player tasks. Every transition may possess a tape command 
requirement, which is denoted by the keyword TAPE and followed by the name 
of the tape command. Every transition may possess either a local or a remote en- 
abling function. Local enabling functions use the keyword ENABLEJLOCAL, 
and are followed by the local function name, an Integer corresponding to the de- 
sired action, and a data name. A small data object manager exists in the player, 
which handles the local variables. Remote enabling functions use the keyword EN- 
ABLE JEIEMOTE, and are followed by the task name that performs the function, 
an integer indicating the desired action, and list of comma separated data objects. 
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Finally, every transition may possess either a local or a remote post function. The 
post functions use the same format as the enabling functions, but use the keywords 
POST-LOCAL and POSTJRJEMOTE, respectively. 

4.4.2 Enabling and Post Functions 

The enabling and post functions are grouped into two cletsses: local and re~ 
mote. The local functions are compiled into the player task itself, and are available 
to all applications. These functions are executed and immediately completed upon 
the firing of a transition. 

The remote functions are independent of the controller, and require that some 
other t^lsk is available to perform the action. When a post function needs to be 
executed, the player sends a message to the appropriate servicer indicating that 
the function has been called. The player then continues with its normal execution 
sequence, leaving that particular transition in a firing state. Once the action is 
completed, the servicer sends a message to the player indicating that the transition 
can finish bring. This corresponds to the three transition firing phases discussed in 
Section 2.2. 

4.4.3 Display File 

The display configuration file provides the relationship between nodes in the 
display to nodes in the players. This allows the user to control the display content, 
either to reduce complexity or stress certain behaviors. Each place in the display 
Petri net is directly mapped to a place in a player Petri net. Transitions in the 
display are either mapped to a single transition or a pair of transitions. When 
two transitions are specified in the mapping, the firing of the first transition in the 
player starts the fixing of the transition in the display. The transition’s symbol is 
highlighted in the display while the transition is firing. When the second transition 
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of the pair completes its firing, the transition in the display completes as well. This 
allows a subnet of the actual player Petri net to be represented as a single transition 
in the display. The configuration data for a display file starts with the line; 

DISPLAY task_name primary ^player 

This identifies the file as a display configuration file, and includes the symbolic 
task name for this display and its primary player. The primary player indicates 
which player Petri net, if any, should be the recipient of the user runtime commands 
entered in this display that affect a single player. The format of a place consists of: 

PLACE local.name remote.name remote.ovner 

The local-name is the name of the place that is displayed. The remote-name is the 
name of the place in the player Petri net which we want to display. The remotejowner 
is the task name of the player owning the remote place. The format of a transition 
is: 

TRANS local-name [SINGLE remote.name remote-ownei] 

I [DOUBLE start-name start -owner end-name end-Owner] 

SINGLE is used when there is a direct mapping for the transition, while DOUBLE 
is used when start firing corresponds to one transition and stop firing corresponds 
to a different transition, as discussed above. 

4.5 User Interface 

The user interface is implemented in the display Petri nets, and allows the user 
to control not only display features but the actual e.xecution of the underlying Petri 
net. This interaction is provided by a combination of mouse and keyboard actions. 
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Table 4.1: Display Commands 


Cause 

Effect 

Arrow Keys 

Shift the Petri net in the direction of the arrow. 

<,> 

Scale the size of the Petri net down or up. 

T.t 

Toggle the tags on the nodes on or off. 

R,r 

Redraw the Petri net. 

0,1, ... ,8,9 

Toggle the enabling of the different display layers 
on or off. (Every element appears in layer 0) 


4.5.1 Display Control 

The user can manipulate the display in a number of ways for more efficient 
viewing of the application. These features are accessed through the keyboard, and 
are described in Table 4.1. 

4.5.2 Player Control 

The user can directly affect the execution of the underlying Petri net through 
the display. These actions are accessed through both the keyboard and the mouse. 
Table 4.2 describes the available commands. 

4.6 Summary 

This controller offers a simple, user friendly method of constructing and ex- 
ecuting a distributed application. The interface to the external functions provides 
a flexible mechanism that will satisfy the needs of future applications of this con- 
troller. The user interface is also extremely flexible, both in terms of the actual 
display content and the display options. 
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Table 4.2: Player Commands 


Cause 

Effect 

S 

Set the entire application into single-step mode. 
An enabled transition will only fire when the 
user clicks on it with the mouse pointer. 

s 

Set the primary player for this display 

(as indicated in the display configuration file) 

into single-step mode. Other players are unaffected. 

C 

Set the entire applit ' Icn into continuous mode, 
where enabled transitions will hre as fast as 
possible. 

c 

Set the primary player for this display 

(as indicated in the display configuration file) 

into continuous mode. Other players are unaffected. 

Selecting a 
transition 
by mouse 

Fire the transition if it is enabled and the 
player is in single-step mode. 

Selecting a 
place 
by mouse 

Left Button: Add a token to the place. 

Middle Button: Prompts user for new token quamtity. 
Right Button: Subtract a token from the place. 

Q,q 

Quit the application. User is prompted to verify. 



CHAPTER 5 

IMPLEMENTATION VS. THEORY 


5.1 Introduction 

Now that the controller has been presented, it is important to verify that 
the implementation maintains the desirable properties of Petri nets. There are two 
issues to be faced: 1) can a distributed Petri net be correctly anadyzed with the 
e.\isting tools; and 2) does the e.xecution algorithm affect the properties of the net. 

5.2 Analysis of Distributed Petri Nets 

Ideally we would like to be able to analyze each Petri net in isolation, and 
from that infer" the properties of the distributed system as a whole. K we can verify 
that the coordination structure maintrins these properties, we can then develop and 
emalyze each net independently. 

This approach of analyzing the individual components to determine the global 
properties can be viewed as a synthesis problem. Can we begin with a single Petri 
net, and synthesize other connected Petri nets in such a fashion as to maintain the 
desired properties? If so, then the individual Petri nets in this connected structure 
can be constructed utilizing these synthesis techniques, and it can be shown that 
the global properties are unaffected. 

This problem can be solved with a top-down synthesis technique, where an 
aggregate model is repeatedly refined [21). This technique consists of refining a 
single transition with a well-formed block, shown in Figure 5.1. This transition 
must not be 2-enabled (the number of tokens in its input places is only sufficient 
for a singes firing), and it is replaced with a well-formed block with these three 
conditions: 
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Figure 5.1: A Well-Formed Block 


• The associated Petri net is live, 

• The input transition to the block is only enabled when the associated net is 
idle, 

• The input transition is the only transition enabled by the initial marking of 
the associated net. 

Under these conditions, the liveness and boundedness of the overall net is preserved. 
The task here is to create a coordination structure for communication between two 
nets. 

The coordination structure presented earlier does indeed meet the conditions 
for this synthesis technique. 

• The coordination structure itself is live and bounded, and one of the previously 
discussed analysis tools can be used to verify whether the remainder of the 
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Petri net is live or not. 

• The semaphore S ensures that the input transition begin is enabled only when 
the Petri net is idle. 

• The use of places ready and S act to enable only begin under the initial 
marking. The initial marking of the remainder of the Petri net should not 
enable any other transitions. 

Therefore, this coordination structure allows the isolated Petri nets to be verified 
as live and bounded independently of the other nets, and maintain those properties 
system wide. 

There Me a number of coordination structures that could be developed, but 
care must be taken to insure that they are valid. The coordination structure that was 
proposed by Wang [22] [25] in his development of the Petri Net Transducer contains 
a subtle error. This original coordination structure, along with the current version 
and a simplified implementation are shown in Figure 5.2. The origined structure 
contained two semaphores, SI and SO. This mechanism was chosen to speed the 
execution of sequential requests. In theory, once an operation was completed, it 
could be communicating the results to the calling Petri net while another action was 
begvm. However, this arrangement dees not necessarily notify the correct transition 
of the completion of an operation, as the following scenario demonstrates. 

Two separate begin - end pairs wish to request an action from a single Petri 
net. The input semaphore SI correctly allows only one of the begin transitions to 
fire. Once the first action is complete, transition finish will fire. This restores the 
input semaphore, and puts a token in place O. This is where the problem occurs. 
The second begin transition is now enabled and can fire. If it fires before the first 
end transition does, there will be a token in both in_progress places. This means 
that both end transitions are now enabled, and that either one could fire. If the first 
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end fires, then there is no problem. However, it is possible for the second end to fire 
first, and this is a violation of the correct net structure, as the firing of the second 
end should correspond to the completion of the second operation, which is still in 
progress. This type of behavior is not only incorrect, but can be dangerous in a real 
system such as the CIRSSE testbed, where the controller is operating physically 
powerful and quick manipulators. 

There are other possible valid coordination structures, as stated above. One 
such structure is shown at the bottom of Figure 5.2. This is a simplified (in terms 
of number of transitions and places) version of the current coordination structure. 
It removes a layer of transitions and places from the connection, but does not of- 
fer the intuitive structure of the current implementation. Futvire work includes the 
development of a coordination structure that allows a Petri net to perform parallel 
operations, while still maintaining the ability to anadyze the net in isolation. A 
parallel implementation can greatly enhance the utilization of the underlying hard- 
ware, and reduce the time necessary to complete some global task. A good example 
occurs in the motipn coordinator, where it would be desirable to allow both manip- 
ulators to move simultaneously, which is not possible with the current coordination 
structure. 

5.3 Execution Algorithm 

It has been shown that a distributed Petri net maintains the desirable prop- 
erties of a single net. Therefore, we wish to examine the behavior of the actual 
execution algorithm in reference to the properties of Petri nets. It will be shown 
that the chosen algorithm does not fully uphold the property of fairness, as well as 
demonstrate that fairness is not strictly necessary for a Petri net controller. 

The execution algorithm consists of randomly selecting a transition to exam- 
ine, and firing it if enabled. Otherwise, progress linearly through the transition list. 
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checking esbch transition until one can be fired. The case of concern is .:hown in 
Figure 5.3, where two trauisitions are enabled by the choice place ready. Suppose 
that the transition starved occurs immediately after transition stuffed in the in- 
terned data structure for the controller. Both of these transitions are enabled when 
there is a token in ready. Following the execution algorithm, a random transition 
is selected for e.xamination. Since stuffed is always enabled when starved is, and 
it occurs immediately before starved in the data structure, it will be fired first 
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unless starved is selected directly by the first random choice. This can be signif- 
icant if the remainder of the net has a large number of transitions. Taken to the 
e.xtreme, if only these two transitions are enabled in a large net with thousands of 
transitions, then stuffed will be fired thousands of times more often than starved. 
Fortunately, this behavior is very uncommon in controller applications. Due to the 
distributed nature of many systems, the individuad Petri nets tend to be small and 
manageable. Secondly, very few control algorithms have a true choice place. The 
common transitions will typically have an enabling function or tape requirement to 
control the final selection of which transition to fire. 

5.4 Summary 

Through the use of a consistent interconnection scheme, distributed Petri nets 
can be analyzed in isolation, and provide information about the system as a whole. 
Additionally, the implementation presented here maintains all of the desirable prop- 
erties of Petri nets that are relevant to controller applications. 


CHAPTER 6 

CASE STUDY: THE CIRSSE TESTBED 


6.1 Introduction 

This chapter describes the architecture of the CIRSSE dual arm robotic testbed, 
and presents two case studies demonstrating the integration of multiple subsystems 
through the use of this controller. 

6.2 The Dual Arm Robotic Testbed 

The Theory of Intelligent Machines [18] [20] presents a hierarchical structure 
for the organization of an autonomous robotic system. This hierarchy is based on 
the principle of Increasing Precision with Decreasing Intelligence. There are three 
distinct levels to this hierarchy: the organization level which provides for global task 
pl anni ng; the coordination level which serves to integrate the physical capabilities of 
the system and decompose global plans into a sequence of lower-level operations; and 
the execution level which consists of the actual hardware and low level functional 
capabilities. 

This structure has found an implementation in the CIRSSE dual arm robotic 
testbed [9] [26]. The execution level is segmented into two subsystems: the Motion 
Control System (MCS) and the Vision Services System (VSS). MCS is responsible 
for interfacing with the low level capabilities of the manipulators. The hardware 
consists of two 6 degree-of-freedom PUMA robotic arms each mounted on a 3 degree- 
of-freedom cart which moves along a common linear track. This provides for a total 
of 18 degrees-of- freedom. The MCS software is e.xecuted on a dedicated VME cage, 
running the VxWorks operating system. VSS is responsible for interfacing to the 
cameras and image processing hardware. Five cameras may be used for stereo or 
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mono vision purposes; two are mounted to the ceiling, two are mounted on the end- 
effector of one robot, and one which is not yet dedicated. A laser scanner is available 
for pointing or pattern projection. These devices are connected to a Datacube image 
processing system residing in a VME cage. 

The coordination level is of primary interest to this thesis, as the Petri net 
controller resides here. The coordination level receives commands from the organi- 
zation level, and decomposes them into portions xnemageable at the execution level. 
The coordination level contains two interior levels, consisting of a dispatcher and a 
number of coordinators. 



Organization Level 


Coordination Level 


Execution Level 


Figure 6.1: The Hierarchy of an Intelligent Machine 


The hierarchical configuration of an intelligent machine is shown in Figure 6.1, 
where it is apparent that the coordination level is also arranged hierarchically. The 
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dispatcher and coordinators are all player tasks in the controller. The coordinators 
represent the capabilities of their particular subsystem, while the dispatcher serves 
to decompose high-level commands into lower- level commands suitable for the indi- 
vidual coordinators. Another feature to note is that the coordinators are designed 
to process only one action at a time &om the dispatcher. This does not preclude a 
particular coordinator from performing concurrent operations in order to process a 
particular command. 

6.3 Case 0: Camera Calibration 

Before the testbed can be fully utilized, the ceiling cameras must be calibrated. 
The algorithm for this process is simple, yet it makes full use of the key concepts 
developed for the controller. A light source is placed in the open gripper of one of 
the manipulators. The manipulator grasps the light, and moves it to a fixed number 
of positions in the viewing region of the ceiling cameras. At each position the vision 
system determines the position of the light in terms of camera coordinates, while the 
motion system determines the position of the light in terms of world coordinates. 
These values are stored in a file, and can be accessed as needed by the various 
components. Once all of the data points have been obtained, the camera calibration 
parameters are calculated, thereby completing the camera calibration process. 

This distributed system has been analyzed using the Petri net tool GreatSPN 
and the method presented in Section 5.2, and was found to be live and bounded. 
Each Petri net was analyzed in bolation, and their individual properties of live- 
ness and boundedness can be applied to the system as a whole due to the use of 
coordination structures for inter-net communication. 

6.3.1 Dispatcher 

The dispatcher serves to parse high-level commands into lower-level commands 
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understandable by the individual coordinators. In this case, the dispatcher performs 
the overall algorithm, while the coordinators control their respective systems. The 
display and player Petri nets for the dispatcher are shown in Figure 6.2, which are 
the upper and lower Petri nets, respectively. Here you can see that the Petri net 
shown on the display is a slightly simpliAed version of the underlying net, omitting 
the communications details necessary for interfacing with the coordinators. 

The command calibrate.camera is given to the dispatcher by placing a token 
in the place calibrate. This enables the transition initjcalib if the robot and 
camera are available. The transition init.calib in the display represents the two 
initialization transitions in the player, namely init_calib and init Joop. Init-calib 
in the player executes the remote post function which opens the Ale containing 
the calibration points. Init Joop executes a local post function which initializes a 
loop variable to the number of calibration points. The transitions decjcntr and 
read.pos decrement the loop variable and load the next calibration point from 
the Ale, respectively. The transition move_robot corresponds to a coordination 
structure which r^uests the motion coordinator to move to the destination position. 
This transition does not complete its Axing until the motion coordinator replies that 
it is done. The net now splits into two parallel paths, demonstrating the ability 
to perform concurrent operations. The transition And.pos is another coordination 
structure which requests the motion coordinator to And the exact location of the 
robot, while save_pos stores this value in a Ale. The transition findjspot is a 
coordination structure which requests the vision coordinator to locate the bright spot 
in the cameras Aeld of view, and save.jspot stores this value in a Ale. This process of 
moving and storing location information is repeated a number of times corresponding 
to the loop variable. The transition pair loop^gain and loop.done perform the 
actual looping action. An enabling fimction is attached to each transition, which 
checks the status of the looping variable. If the loop variable is now zero, then 
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loop^one is enabled, otherwise loop^ain is enabled. After all of the calibration 
data has been obtained, the loop is exited and callb.calcs fires. A post function 
performs the calculation of the camera calibration parameters, and the resources 
are retximed. 

6.3.2 Motion Coordinator 

The coordinators reflect the capabilities of their particular subsystem, hiding 
many of the details flrom the dispatcher. The motion coordinator is very simple for 
this case, possessing only two actions callable by the dispatcher. The display and 
player Petri nets are shown in Figure 6.3, and you can see that both Petri nets are 
identical. The transition do_find.pos queries the motion servicer for the position of 
the manipulator used for the calibration. The other transition dojtnove activates 
the portion of the net that is responsible for moving the robot. Two paths exist 
within this action, depending upon whether a path plan already exists or not. If 
the path already exists (and for this case it does, as the dispatcher is simply ex- 
ecuting moves toj>replanned robot joint positions) we can proceed to moving the 
manipulator via validate.path and movejmanip. Otherwise, the motion coordi- 
nator would Are plan.path to generate a path, and then move.jnanip to move 
the manipulator. 

6.3.3 Vision Coordinator 

The vision coordinator for this case represents the minimum Petri net structure 
for a coordinator. The display and player Petri nets are shown in Figure 6.4, and 
like the motion coordinator, they are identical. There is only one action callable by 
the dispatcher, and is activated by transition do Jindjspot which locates the light 
spot in the camera’s Held of view and stores its position in the DOM. 
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MC-SI MCJ MC.0 MCLSO 



MCJSI MCJ MC.O MCJO 



Figure 6.3: Case 0: Motion Coordinator Display and Player 


4 ; 




Figure 6«4« Cese 0; Vision 


Coordinator Display and Player 
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6.4 Case I: Strut Insertion 

This case considers a more difficult task which is more representative of a 
typical use of the robotic platform. A partially completed strut and node triangle 
is placed on a table, and the task at hand is the insertion of the third strut to 
complete the triangle. This task is significantly more complicated than the camera 
calibration, with about an order of magnitude more transitions and places. This 
problem is shown in Figure 6.5. 

This case study has not been fully executed yet, as the functional code for the 
path planner is currently under development. However, the controller is being used 
for the testing and debugging of those modules still under construction. 

6.4.1 Dispatcher 

The dispatcher for this application makes good use of the controllers ability to 
perform parallel operations, as well as to coordinate the sequencing of asynchronous 
events. Due to the size and complexity of this net a transition by transition expla- 
nation will not be given. Rather, a verbal overview of the dispatcher’s actions will 
be presented. The Petri nets for the display jmd player tasks are shown in Figures 
6.6 and 6.7, respectively. 

The triangle completion begins by initializing the vision system in parallel with 
the manipulator and path planning systems. Note that the path planner cannot 
begin initialization until the robot is initialized, since it requires knowledge of the 
position of the robot and must move it to the home position if it is not already 
there. 

The vision system must now locate the partially completed triangle, and cal- 
culate the approximate position of the first uncompleted node. The path planner 
plans a path to this node, and the motion system moves the manipulator to it. 
While the arm is in motion, the path planner is already calculating the path to the 
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Figure 6*5: Case Study 1: Strut Insertion 
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Figure 6.6: Case 1: Dispatcher Display 


r 



Vision Motion Path Planner 

Coordinator Coordinator Coordinator 


Figure 6.7: Case 1: Dispatcher Player; Note the Complexity versus 
the Dispatcher Display Petri Net 
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second node. The camera’s on the arm now locate the node more accurately, and 
the arm moves to the second node where its location is refined as well. 

While the location of the second node is being refined, the path planner is 
calculating a path to the rack containing extra struts. Once the arm is available, 
it moves to the rack and picks up a strut. During this time, the path planner is 
first calculating a path to insert the strut in the uncompleted triangle, and then to 
move to some final safe position. The arm moves to an approach position over the 
triangle, and inserts the strut. 

T*'e triangle is now complete, so the robot moves to the safe position, and the 
three subsystems are shut down. 

The dispatcher for this case provides a good example of why such a flexible 
display system was developed. The algorithm given above is cle^lr in the display 
Petri net, where each action to be performed by the coordinators is represented 
by a single transition. The coordination structures in the player Petri net make it 
very difficult to understand, with a large number of arcs crossing each other as well 
as the individual places and transitions. The coordination structures for the three 
coordinators are indicated in the boxed regions at the bottom of the figure. The 
upper boxes labeled Arb correspond to the Arbitration portion of the structures, 
where access to the particular coordinator is controlled. The lower boxes labeled 
Com correspond to the different commands offered by each coordinator. Note that 
the tags for the places and transitions are not shown in the player Petri net, since 
they were illegible. 

6.4.2 Motion Coordinator 

The player Petri net for the motion coordinator is shown in Figure 6.8, and it 
contains seven operations. The transitions dounit^obot 2 tnd do^hutdownjrobot 


51 


are used to initialize and shutdown the robot. The transition doJInd^pos deter- 
mines the exact position of the robot, as known by sensors on the manipulator itself. 
The last four transitions perform different t}rpes of move commands, ranging from 
a general move to a specific sequence such as inserting a strut into a node pair. 

6.4.3 Vision Coordinator 

The player Petri net for the vision coordinator is shown in Figure 6.9, and it 
performs five operations. Similarly to the motion coordinator, two of these tran- 
sitions, doJnit_camera and do_shutdown_camera, are used to initialize and 
shutdown the camera system. The transitions do.£nd_spot and do^ndjobject 
locate the bright spots and a particular object, respectively. The last transition, 
do^efine 4 >ose, more accurately determines the location of a node through the use 
of the arm cameras. This requires that the node must be located relative to the arm 
cameras, and that the position of the ceuneras be known. The location of the node 
in world coordinates is determined after these two parallel operations complete. 

6.4.4 Path Planner Coordinator 

The path planner coordinator is slightly different &om the other coordinators 
in that it has no direct execution level counterpart. The path planner is strictly a 
software module, and is not responsible for interfacixig to any hardware. 

The player Petri net for the path planner is shown in Figure 6.10, and it con- 
sists of five operations. Two transitions, doJnit J*P and do^hutdownJPP, are 
responsible for the mitialization and shutdown of the path planner. The remain- 
ing transitions calculate different kinds of paths, ranging from a simple start-to-end 
point path, to specific paths such as a current position to approach position for 
insertion path. 
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MC.SI MCJ MCLO MCLSO 



Figure 6.8: Case 1: Motion Coordinator Player 














PC.SI PCJ PC.0 PCLSC 



Figure 6.10; Case 1: Path Planner Coordinator Player 
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6.5 Summarv 


The capabilities of this controller ha\’e been demonstrated through two case 
studies on the CIRSSE dual arm robotic testbed. Case study 0 hai been uhple- 
mented and executed, successfully providing a method for the simple control over 
calibrating the stereo ceiling cameras. The functional code for case study 1 is still 
under development, and the controller is providing a user ^pdly metihod of testing, 
the individualcomponents as they are constructed. / f 7/ il. 




CHAPTER 7 

CONCLUSIONS AND FUTURE RESEARCH 


^.1 Conclusions 

jj 

This thesis described the need for a toot which could provide some means of 
modeling, integrating and controlling an application. A Petri net based controller 
was presented as a solution, and two case studies demonstrated that it could satisfy 
these criteria for a distributed heterogeneous hierarchical system. Its maun strengths 
are?: 

• A controller algorithm based on Petri nets which allows the system to be math- 
ematically analyzed for performance and desirable properties such as liveness, 
boundedness, etc. 

• Straightforward design and interconnectivity of the individual Petri nets. 

• Compatible with CTOS 

— Fully integrated with the Execution-level services provided by MCS and 
VSS. 

— Easily configurable for distributed and heterogeneous applications. 

• Demonstrated parallelism of the CIRSSE testbed 

~ Modeled and controlled a hierarchical configuration. 

— Provided for the operation of a multiprocessor system. 

• A user friendly graphical interface foi the monitoring and control of each Petri 
net. 
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• Highly configurable displays for the more efficient representation of the under- 
lying Petri net control structure. 

7.2 Future Research and Modifications 

• Expand the firing of transitions to record performance data. This information 
can be used to enhance the analysis of the net with one of the previously 
mentioned tools. Remember, those modeling toob require that the user enter 
his best guess for timing parameters. Initial estimates can be made and then 
enhanced as the system is implemented for more refined modeling. 

• Supplement keyboard commands with equivalent on-screen X-window gadgets. 
Many operations, such as scrolling the display, would be more efficient with a 
mouse and gadget interface. 

• Construct an event handler task for editing and sending Petri Net Transducer 
tapes to the player tasks. 

• Provide for outlining or otherwise marking sections of the Petri net in the 
displays. This would allow for visible segmentation of associated groups within 
the Petri net. 

• Develop or enhance existing Petri net design tools such as Xpn or GreatSPN 
to fully support the creation and modification of the player and display con- 
figuration files. 
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APPENDIX A 

Local Enabling and Post Functions 

The local enabling and post functions were initially implemented to provide a means 
of performing deterministic looping behavior. They have been expanded to include 
any functions that are relatively small, generic to many applications, and linked to 
the player code. 

A.l Enabling Functions 

done action data^name 

Use: To check the state of a local variable. 

Returns: TRUE if the contents of data.name = 0, 

FALSE otherwise. 

This behavior holds when action » 1, 
if action * -1 the logic is reversed. 

00M_done action data_nane 

Use: To the state of a variable in the DOM. 

Returns: '^.T*JE if the contents of data_name » 0, 

FALSE otherwise. 

This behavior holds when action ~ 1 , 
if action » -1 the logic is reversed. 

D0M.bool action data.name 

Use: To check the state of a variable in the DOM. 

Returns: FALSE if the contents of data.nane » 0, 

TRUE otherwise. 
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This behavior holds vhen action ■ 1, 
if action » -1 the logic is reversed. 

A.2 Post Functions 

initialize action data^name 

Use: To initialize a local variable to a fixed value. 

Operation: Sets the contents of data.nase to action. 

live.init actios data.name 

Use; To initialize a local variable to a runtime value. 
Operation: Prompts the user to enter the desired value, 
and sets the variable data.name. 

decrement action data^name 

Use: To decrement a local variable by a fixed value. 
Operation: Subtracts action from the contents of data.name. 

increment action data.name 

Use: To increment a local variable by a fixed value. 

Operation: Adds action to the contents of data.name. 

renameObjs action data_name 

Use: To rename a variable in the DOM. 

Operation: Here data.name is the comma delimited source 
and destination veuriable names. 


dupObjs action data^name 



Use: To duplicate a variable iu the DOM. 

Qperatiou: Here data.aaAe is the comma delimited source 
and destination variable names. 

alive action data^name 

Use: To print a flag vhen a transition fires. 

Operation: Prints the string "alive: " followed by 
the integer value of action. 



APPENDIX B 
Header Files 


B-1 GlobaLvar.h — The Global Variables 

/« CTOS variables */ 

TID.TYPE globTid; 

/• X-^isplay variables */ 

Display ^display; 

Vindoe *vindov; 

GC gc; 

XFontStruct *loBt[4], *act_font; 

int screen_nua; 

char display.nameClOO] ; 

/♦ Size variables */ 

iat diaoketer, radius, raditis2: 
float scale, ollset.z, offset_y; 
unsigned int line.vidth; 

/♦ user options */ 

int ault, tags.on, rates.on, visible.layer = Oxflff; 
int mode ~ SIHGLE.STEP; 

TID.TYPE playTid; 

/* net objects */ ' 

struct Place eplace; 
struct Trans *trans; 
struct MPar *npeir; 
struct RPar *rpar; 

int nun.ap, nua_pl, nua_zp, num_tr, nua_gr, nun.cs; 

char *net_nama ; 

/• tape variables */ 

struct tape.node «haid, *tail; 

struct tape.entry tape.tableD = 

•C{l,"MaVE”>, 

<2,”GiUSP"}, 

<3, "LOOK”}. 

{4, '•STOP"), 

{S,"CAL_VIS") 

>; 
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B.2 GlobaLvar.p — The Global Variable Prototypes 

/* CTOS variables •/ 

extern T3)_TYFE globTid; 

/* X-display variables */ 

#include <Xll/Xlib.li> 

extern Display «display; 
extern Windov evisdoe; 
extern GC gc; 

extern XFontStmct *font[4], *act_font; 
extern int screen.num; 
extern char display.naneLlOO] ; 

/♦ Size variables */ 

extern int diajseter, radius, radios2; 
extern float scale. offset_r, offset_y; 
extern unsigned int line.nidth; 

/♦ user options */ 

extern int mult, tags.on, rates.on, visible.layer; 

extern int mode; 

extern TID.TYPE playTid; 

/* net objects •/ 

extern struct Place eplace; 
extern struct Trans *trans; 
extern struct NPar *mpar; 
extern struct RPar *rpar; 

extern int num.mp, nun.pl, num.rp, nan_tr, num.gr, nun.cs 
extern char *net.name ; 


/* tape variables */ 

extern struct tape.node *head, *tail; 
extern struct tape.entry tape.tableQ ; 


B.3 GlobaLdef.h — The Global Definitions 

/* 

FILE: Global.def.h 


*/ 

/* general defines •/ 
#define HAXLINE 255 
/* modes of operation •/ 
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tfdafina COHTZHUQUS 1 
fdafina SIHGLE.STEP 2 

/* transition ID*s •/ 

tfdafina EXP 0 
tdafina IMM 1 
«defina DET 127 
«dafina DEFAULT 200 

/* arc ID'S •/ 

tfdafina IMPARC 0 
«dafina OUTARC 1 
Sdafine IREARC 2 

/* type of coafig fila •/ 

#define CF.PRET (l) /* coufig fila for subnet player */ 

#define CF_DIS? (2) /* config file for subnet display */ 

/* type of net node */ 

#define PLACE.RODE (0) 

#define TRAffS.EODE (l) 

/* graphics defines */ 

#define PIX.PER.IH 60 
#define SCALE 1 
«define DIAMETER 23 

#define IB_TQ_PIX(a) (int)((a)*PIX.PER.II) 

♦define X_IS_TO.PII(a) (int)(IJr.T0.FIX(a)*scale+II_T0_PIX(offsat x)) 

♦define Y.IS_TO.PIX(a) (int)(II_TO_PIX(a)*scale+IH_TO.PIX(offset_y)) 

♦define AEG (M.PI/12) 

♦define max(a,b) ■C((a)>(b}}? a:b) 

♦define ERASE 0 
♦define DRAV 1 
♦define IRVERT 2 
♦define S 0.4 
♦define M 0.5 
♦define L 0.7 

/• net elements •/ 

♦include <ctos.h> 

typedef unsigned int UIRT ; 
typedef unsigned short USHORT ' 

♦define T.START 0x01 
♦define T_ERD 0x02 
♦define T.BOTH 0x03 

typedef struct .updlst 

{ 

TID.TYPE tid ; 

USHORT num ; 

USEORT shich; /* start or end firing of trams «/ 

struct .updlst «next ; 
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UPDATES ; 

struct Arroehead 

{int x0,y0,xl,yl,x2,y2; 

h 

struct Arc_point 
<int x,y; 

float x.ia, y.in: 
struct Arc.poiat *next; 

>: 

struct Arc 

{iat x.start, y.start; 

float x.start_itt, y_start_in; 
struct Are.point *arc.points; 
int x.end. y.«nd; 

float x_end_in, y_end_in; 
int type ; 

int mult ; 

int place; 

int layer; 

struct Arrovliead *arrou; 


struct Arc 
>: 

♦next; 

struct Place 

Cellar 

♦aame; 

UIBT 

id ; 

int 

orig_token; 

int 

curr .token; 

int 

*_loc, y.loc; 

float 

x.loc.ia, y.loc.: 

int 

tag_x, tagj; 

float 

tag_x_in, tag_y_: 

int 

layer; 

int 

locked ; 

int 

tid; 

TID.TYPE 

owner ; 

ch.ao' 

♦act .name; 

UPDATES 

♦update : 


>; 


struct Trans 
Cchar 

♦name; 

char 

•act.name; 

char 

♦act.end.name; 

uirr 

id ; 

UIST 

end.id ; 

float 

fire.rate; 

int 

kind; 

int 

orient ; 

int 

y_loc; 

float 

x.loc.in, y.loc.ia; 

int 

tag.x, tag.y; 

float 

tag.x.in, tag_y_in; 

int 

rate_x, rate_y; 

float 

rate.x.in, rate.y.in 


struct Arc •inp.arc; 
struct Arc •out_arc; 
struct Arc *i2dx.arc: 



iat 

layer; 

Int 

firing; 

int 

tape.req; 

int 

enable.type ; 

int 

(*enabla_lnncK) 

int 

enable.action; 

int 

enable. var; 

char 

*enable.data; 

int 

post .type; 

void 

(*post_laac)() ; 

TID.TYPE 

post. t id; 

int 

post. action: 

int 

post.var; 

char 

epost.data; 

TID.TYPE 

osner ; 

TID.TYPE 

end.oener ; 

UPDATES 

^update ; 


>: 


struct MPar 

■Cchar 

«name; 

int 

nun.token ; 

int 

tag.x, tag_y; 

float 

tag.x.in, tag_y.in; 

int 

layer; 

>; 


struct RPar 

■Cchar 

«aame; 

float 

fire.rate; 

iat 

tag.x, tag.y; 

float 

tag.x.in, tag_y.in; 

int 

layer; 

}; 


/ * struct 

for registering P h 

typedef struct 

W 

char ‘ 

*sym.name [64] ; 

char ‘ 

•act.naae [64] ; 

int 

type ; 

int 

id : 

USHORT 

ehich; 

} 


REG_REMOTE 



/* Tape stall */ 

Sdeliaa KAX^TAPE 5 

struct tape.aode 
•Ciat id; 

struct tape.node *a«zt; 


struct tape.entry 
■Ciat id; 

char *ideat_str; 

>: 


/* enable and post function stuff «/ 


«defin« F^VOHE 0 
tfdeflne F.LOCAL 1 
tfdefine F.REMCTE 2 

#defino REHOTE.POST.FUNC '*send.post_message“ 

struct func.entry 
{int (•func_ptr)(); 

char *ident.str; 

>: 


tdefine OBJ.IAME.LENGTE 256 

typed ef struct 

{ 

int indx ; 

int action : 

char data_obj C0BJ_iTAME_LENGTH3 ; 

} 

POST.DATA; 


A variable stuff ♦/ 

«define HA2.VAR 200 

struct var_«ntry 
-Cint value ; 

char ♦ident_str; 

>: 


A macro dofinitions */ 


#define MAKE.ID(tid, typo, indr) ( (((tid )«16) ft OxffffOOOO) 
I (((type)«lS) ft 0x00008000) \ 

I ( (indx) ft OxOOOOTfff)) 


ftdofine TID.FIlQM_ID(id) 
•define l-yPE_FROM.ID(id) 
•define HOEX_FEaM_IO(id) 

•define EICQOE.BUTrOH(b,id) 

•define GET.BOTTOI(id) 
•define GET.IBBEX(id) 


( ((id) ft OxffffOOOO) » 16 ) 
( ((id) ft 0x00008000) » IS ) 
( (id) ft OxOOOOTfff ) 

( (((b)«16) ft OxffffOOOO) \ 
|( (id) ft OxOOOOffff)) 

( ((id) ft OxffffOOOO) » 16) 

( (id) ft OxOOOOffff ) 


•define LEFT 
•define RIGHT 
•define UP 
•define OOVM 


OxOOCOOOOl 

0x00000002 

0x00000004 

0x00000008 


•define HORI_SHIFT(id) ( (((id) ft LETT) * -1) \ 

+ (((id) ft RIGHT) » 1) ) 

•define VERT«SHIFT(id) ( ((((id) ft UP) » 2) • -1) \ 

+ (((id) ft DQWH) » 3) ) 


•define SCALE.FACTOR 0.1 
•define DEC -1 
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B.4 msg.h — The Controller CTOS Messagef 

/* Message comBands */ 

Adeline MSG.CCQRD 11000 


Adeline NSG.0RAU.VB0LE.9ET 
Adeline HSC.SET.TOK 
Adeline HSG.START.TRAHS 
Adeline HSG.EHD.TRABS 
Adeline HSG.APP.TAPE 
Adeline NSG.ZMS.TAPE 
Adeline MSG.CLR.TAPE 
Adeline HSG.ABS.TAPE 
Adeline HSG.AOD.TOKEN 
Adeline MSG.SUB.TQKEN 
Adeline MSG.CHK.FIRE.TRANS 
Adeline HSG.TRAHS.FZRED 
Adeline HSG.TRANS.DONE 


NSG.COORD-i’l 

NSG.COCRD4-2 

MSG.COORD+3 

NSG.CaORD-^4 

MSG.CQ0IU)<^5 

NSG.CQORO-i>6 

NSG.C00RO4-7 

NSG.CQORO-t-8 

NSG.COORO+O 

MSG_COOBD+10 

MSG.COORD+11 

MSG_CQO{lO-i-12 

HSG.COORD+13 


/* Mouse Actions */ 

Adeline MSG.SELECT.TRAMS MSG_C00RD+20 

Adeline MSG.SELECT.PLACE MSC_C00RD+21 


/* Keyboard Actions */ 
Adeline NSG.CEAHGE.SCALE 
Adeline HSG.SHIFT.DISPLAY 
Adeline MSG.TQGGLE.TAGS 
Adeline MSG.SET.MODE 
Adeline MSG.VISZBLE 


MSC^CQORD+30 

MSG.COORO>31 

NSG.CaORD-t>32 

MSG.COORD+33 

HSG.COQRO+34 


Adeline HSG.SZT.OB.HANDS MSG_CQQRO-»-40 


Adeline 

Adeline 

Adeline 

Adeline 

Adeline 

Adeline 


MSG.YOU.ARE MSG_CC0RD+51 
MSG_IHIT_DISPLAY MSG.COORD+52 
MSG.IIIT.PLAYER MSG.COOaD+S3 
MSG.REGISTER.REMOTE MSG.COaRO-^54 
MSG.COXFIBM.REHOTS MSG.COORD-i-SS 
MSG.REGIS7ER.UPOATE MSG.COORO+Sd 



APPENDIX C 
Player Software 


C.l makefile — The Player Makefile 

# Makefile lor test of UHIX versicB of CTQS 

IHCl 3 /home/page/NCS/src/lib/bta'^b 
IHC? 3 /hone/page/NCS/src/lib/ns(;Lib 
IHC3 3 /home/page/MCS/sre/lib/etosShell 
IKC4 3 /uar2/testbed/CIRSSE/iii8talled/UIIX/h 
IHCS 3 /home/paga/MCS/src/lib/recLib 
1NC6 3 /bome/lefebvre/unix/ctos/doiBLib 
ItfCT 3 /hoffle/lefebvre/DEHOS/damol 

CFLAGS 3 >0 -Vreturn-type -Uoxmsed *>Us?ltch -Weomment -Vshados 
-Wpoiater-arith -DMAKE.SUJf^ -I$(INC2) -I$(IHC3) 

-I$(INC4) -1$(1HCS) -I$(INC6) -I$(IKC7) -DOS.OHIX 

BZNDIR 3 /home/page/HCS/biiiysuii4/ 

BTSLIB 3 $(BIEDIR)btsErr.o $(BZHDIR>btsSeffl.o $(3IfiDIlObtsGlobals.o 
$ (aiKDIR)msgLib . o $(BIHDIR)fflsgBCMem.o 
RECOIR 3 /hcir.e/page/HCS/biii/3Uzi4/ 

# List of targets . . . 

« 

all : play.eh 


# E.H. Tasks... -< 

play.eh: play.eh.o Xplay.o load.net. o tape.o msgs.o post.ftmc.o \ 

enable.! nnc . o var.naui.o 

gee $(CFLAGS) -o play.eh play.eh.o Xplay.o tape.o msgs.o \ 
post.fune.o enable.fnne.o load.net. o var.man.o $(RECOIR)recLib.o \ 
3(BTSLIB) |(BIHDIR)etosSbell.o \ 

-L/bome/lefebvre/CEHQS/demol >L/boae/lelebTre/nniz/ctos/dofflLib \ 
“leoord -Idem -Im 


play.eh.. o: play.eh. c Global.var.h Global.dei.h 
gee -c $(CFLAGS) play. eh. c -o play.eh. o 

Xplay.o: Xplay.e Global .def.h 
goo -c SCCFLAGS) Xplay.e *o Xplay.o 

load. net. o: load.net. e Global.de! .h 
gee -e $(CFLACS) load_net.c -o load.net. o 

tape.o: tape.o Global.def.h 
gee -o $(CFLAGS} tape.o -o tape.o 

post.func.o: post.func.o Global.def.h 
gee -c $(CFLAGS) post.luno.e -o post.func.o 
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•&abl«.fune.o: •nable.fune.e Glebal.daf.h 
£cc -c S(CFUCS) «aabl«_tttne.e -o •nablt.fu&c.o 

fflsgs.o: Bsgs.e Global.daf.h 
gee 'C KCFLAGS) msgs.e -o osgs.o 

var_B«a.o: var.man.e Global.daf.h 
gee *e S(CFLAGS) var.Ban.c -o var.aaa.o 


C.2 play.eh.c — The Player Event Handler 

/mmmm**m**m******mmm*************m*m*m****m**m**mm**mmm**mm*m****** 
File: play. eh. e 

Purpose: “Petri Vet Player" ev^<nt handler task executes subnet 

Author: Joe Peck 

revised: Don Lelebvre 


Revised: ;:9 Aug'91 

*»4i*4i«*4i**4i««****«*4-*«*4 

/* 

tinelude <m/Xlib.h> 
tinelude <X11/Xutil.h> 
tinelude <Xll/Xos.h> 
tinelude <Xll/Xatom.h> 


" include files — 


tinelude <stdio.h> 


tinelude <etos.h> 
tinelude <btsLib.h> 


tinelude “reeLib.h" 
tinelude “msg.h" .. 
tinelude “Global.def .h” 
tinelude “Global.var.h" 
tinelude “Xplay.p" 

/*— — — — definitions — — 

/*— global variables — —•/ 

int go « FALSE; 

char root.naaeC40l ; 

char emylaae ; 

char config.fils CMAXLIHE] ; 

STATUS load.uet (char *Bet.config_file. int type) ; 

STATUS register.remote (} ; 

STATUS eonf izB_reBOte (TID.TYPE req, REG.REMOTE *ps) ; 

STATUS save.remote (REG.REMQTE *ps} ; 

STATUS save.update (HSG.TTPE •m) ; 

STATUS initial.Barking 0 ; 

void printPTinfo () ; 

int entires (struct Arc *p) ; 

int find.placa (char enaae) ; 

int find.trans (char *naae} ; 

KyTaak(play.eh) 
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pl&y.«h - sttbaot player for Petri Set 

SYMBOLIC HAKE: (used to confine net) 

RETURHS: 0 Indicatiag processing conplete 

PARAMETERS: TID.TYPE ayTid - task id of event liandler 

NSG.TYPE «asg - pointer to received aessage 

int play.eh (TIO.TYPE nyTid. NSG.TYPE *asg) 

int t.nuffl ; 


■/ 


seitch (nsg->coDaand) 

ease MSG_TASK_ARGS ; 

strcpyCroot.nane, (char *}asg->data) ; 
break; 

case MSG.PIHIT; 

/* setRunTiae (120) ; *l 

/* read display eoafig file */ 
globTid s nyTid; 

ajMans ^ nsgMyTaskBaae (ayTid) ; 

/* sprintf (eonf ig_file, '‘y.s7»s", dir.name, ayHane) ; */ 

if (loadjiet (rootjiane, CF^PIET) » ERROR) 

{ 

recinfo (ayTid, "Unable to load ccnfig file 'Xs.pnet*", 
root .name) ; 

nsgApplicationExit (ayTid) ; 

break ; 

} 

/* recinfo (ayTid, "PIAY: Loaded net ‘%s.paet*\n", root^aaae); */ 
break ; 


case MSG.AIMIT: 

register.renote () ; 
break ; 


case MSG.AEXEC; 
initial_aarking () ; 
go » TRUE; 

/♦ printPTinfo () ; */ 

break ; 


ease MSG.REGISTER.REMOTE : 
confira.reaote (asg->sourca, 
(REG.REMOTE •) msg->data) ; 
break; 


case NSG.C0MFIRH.REH0TE: 
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sav«_r«aot4 ( (R£G,fl£NOTE *) ius->data) ; 
braiJt; 


cas€ MSG.REGISrER.UPDATE: 
sava.apdate (asg) ; 
break; 


case KSG_APP,TAPE: 

r*cInfo(myTid,”PLAY: Received APP.rAP£\n“ ) ; 

appead_tape( (int)iusg->daca} ; 

break: 

ease MSG.IRS.TAPE: 

recIafo(myTid,"PUY: Received IIS.TAPEW ) ; 

insert _cape( (int)msff->data) ; 

break: 

case MSG,CLR_TAPE: 

recInfo(myTid,''PLAY: Received CLR_TAPE\n'*) ; 

cleax.tapeO ; 

break: 

case HSO_ABS_TAPE; 

recInfo(myTid,”PUY: Received ABS.TAPE\a”) ; 

absorb.tapeO ; 

break; 


case MSG.TRAES.DOHE: 

/* recinfo (nyTid, *7.s: Received TRARS«DOBE\n'*, myUfaiiie) ; */ 
lire. end ((in.t)ns 2 ~>data) ; 
break ; 


case «SC.SET_TOK: 

/♦ recinfo (xyTid, **7.s: Received SET_T0K\n", ayH^UBe) ; ♦/ 

set_tokea( C iat )»sg~-Mata) ; 
break ; 

case MSG.AOD.TOKEH; 

/* recinfo (myTid, '7#s: Received ADD^TOKESVn'*, oylfajne) ; */ 

add.toker. ((iat)asg'«>data) ; 
break ; 

case MSG.SUB.TCKEF: 

/* recinfo (eyrie,, "*/.s: Received SUB.TQSEaXn.'* , myflaoe) ; */ 

snb.token ((int)asg->data) ; 
break ; 

case «SG_CaK_F:RE,TRAHS: 

/* recinfo (ayXid, **%s: Received CHE.FIRE,TRA5S\n" , ayHaae) ; */ 

if (go TRUE) 

{if (traas_tok_enablad((iat)asg->data)) 

{if (tran5_pro_«nablad((int)asg->data)) 

{/* recinfo (ayTid, "51s: Firing transition %d\a",ayBa 25 c, 
(int)asg->data) ; */ 

Xire.atart((int)asg->data) ; 
if (done_firing((int)asg'>data}) 

f ire„ead((iat)asg“>data) ; 
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}; 

>; 

>; 

break ; 

case MSG_SET_MODE: 

mode - (iac)msg'>daca; 
break; 

case HSG.ATEL4: 
go = FALSE; 
break; 

> 


/* execute subnet il no asgs are vaiting */ 
if ((go == TRaE)k»(mode ~ COHTURJO'JS) ) 

?b.ile (msgQueueCount(in 7 Tid} == 0) 

•C 

t_num = get_ready_trans() ; 
if (t_num ~~ -1) 

usleep (500) ; 

continue ; 

} 

/* recInfoCnyTid, "NnXs: *** Firing Trans *Xs* CZi] ♦**\n’‘, 
ayHame, trans[t_aniii] .name, t_nnm) ; */ 
f ire_start(t_nuffl) ; 

if (done.firing(t^uB) } 
f ire.andCt.num) ; 

} 

> 

/* execute subnet il no msgs are uniting */ 
if ((go == TatJE)**(mode = SIIGLE_STEP)) 

/* recinf o (ayTid , "7.S checking hidden transitions \n*', rnyHaae) ; */ 
uhile (msgqueueCount(myTid) o) 

t_num = get_ready_hiddan_trans() ; 
if (t_num == -1) 

< 

usleep (500) ; 

continue ; 

> 

/♦ recInfo(globTid, "Firing hidden trans %s\n", 

trans Ct.num] .name) ; ♦/ 

iire_start(t_n’ia) ; 
if (done_fixing(t_num)) 
f ire_end(t.num) ; 

> 

} 

/* exit event handler task via default processing *l 
return (msgDelaultProc (myTid, asg)) ; 

} 
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g«t_apdates - r«tums update list as ctiar string ot tid*s 
char *get_updates (UPDATES *ps} 


static char buf [80] ; 
char *p ; 


•buf = »\0* : 
p = bul ; 
vhile (ps) 

1 

sprintf (p, '• %4x:'/.i‘*, ps->tid, ps->nua) ; 
p = buf + strlen(bul) ; 
ps = ps->ncxt ; 

} 


return (buf ) ; 

} 


/***^**t*****m**t*****************************************************i*****ii** 

printPTinfo - print place A transition information 

****ii**^t***********m*********************************************************/ 

void printPTinfo () 

< 

int i ; 

if (Istmcasecnp (nyPame, **PlfET_A'*, 8)) 
sleep (l) ; 

else if (istmcasecmp (myName, "PKET.B", 6}} 
sleep (2) ; 

recinfo (globTid, “vaaet lame: %s\n'*, myHame) ; 

recinfo (globTid, "PLACES CXi]\n", num_pl) ; 

for (i=0; i<nun_pl; i++) 

/* recTnfo (globTid, "\t5(6s X4.1f %4.1f %2i\n", place [i] .name, 

place Li] -x.loc.in, placed] .y.loc.in, placed] .orig_token) ;*/ 

recinfo (globTid, "\t*/,12s %8x 7,4x 7,s\n“, placed? .name, 
place Ci] . id , place [i] . ovner , 
get.npdates ( place [i] . update) ) ; 

> 

recinfo (globTid, "TRASSITIOSS [y.i]\n", num.tr) ; 

for (i=C; Knum.tr; i++) 

< 

/* recinfo (jjlobTid, "\t7,6s 7,4. If 7,4. If */2i 7,2i\n", trans[i] -name, 
transd] .x.loc.in, trans[i] .y.loc.in, 

cntArcs(transCi] .inp.arc) , cntArcs(trans[i] -out.arc)) ;*/ 

recinfo (globTid, "\t7.12s 7.8x 7,4x 7,s\n'', transd] .name, 
trans[i]>id, trans[i] .owner, 
get.updates (traas [i] .update) ) ; 

> 


> 


/m*t>:**mm«m***>***m**************************’*********m****itmm*****i^**0*iti*****mmm 
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cntArcs - count numbor of arcs in list 


***«**«««*****«4 


int cntArcs (struct Arc *p) 

{ 

int cnt = 0 ; 

ohile (p) 

{ 

P 3 p->noxt ; 
cat++ ; 

> 

return (cnt) ; 

> 


/***0m^^**m»m»»***0m*********»****************»******************‘*mm»m****m**mm 
register.remote - sends request osgs to register remote nodes 

*«**««*e*««3«««««**«***«4 

STATUS register_remote () 


int i ; 

REG.REMOTE ♦ps ; 


/* ser.d msg for each remote place •/ 
lor (i=0; i<nua_pl; i++) 

{ 

if (place Ci] •ooner != globTid) 

{ 

ps = (REG.REMOTE *) malloc (sized (REG.REMOTE)) ; 
strcpy (ps->sym.name, place [i] .name) ; 
strcpy (ps->act.naae . placed] .act.name) ; 
ps->type = PLACE.SODE ; 

msgBuildSend (place Ci] .ovner, globTid, MSG.REGISTER.REMOTE, 
(void *) ps, sizeof (REG.REMOTE), 

MF.STAMDARD) ; 

> 

> 


/* send msg for each, remote transition */ 
lor (i=0; i<num.tr; i++) 

{ 

il (transd] .omner != globTid) 

{ 

ps 3 (REG.REMOTE *) malloc (sizeof (REG.REMOTE)) ; 
strcpy (ps->sym.naine, transd] .name) ; 
strcpy (p3->act_name, transCi] .act.name) ; 
ps->type = TRAHS.HODE ; 

msgBuildSend (transd] -ovner, globTid, HSG.REGZSTER.EEMOTE, 
(void *) ps, sizeof (REG.REMOTE), 

MF.STAHDARD) ; 

> 

> 


return (OK) ; 

> 


confirm.r emote - send return msg vith remote node’s id 


STATUS conf ixm.remote (TID.TYPE reqTid, REG.REMOTE *ps) 
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•C 

int iadx ; 

REG_REMOTE *pret ; 

/• 2dlocata return msg */ 

pret a (REG.REMOTE •) maUoc (eizeof (REG.REMOTE) ) ; 
strcpy (pret>>s7B_naffic, ps->s7D.name) ; 
atrcpy (pret~>act.naiae. ps->act_naae} ; 
prat->type = ps->typa ; 

/* find place or transition */ 
seiteh (ps->typa) 

case PLACE.IOOE: 

/* find local index */ 

if ((indx = find.placa ((char «}ps->act_nana)) < 0 } 

racinfo (globTid, "Could not find place *Xs' by naaeXn". 

ps->act_nane) ; 

free (prat) ; 
return (ERROR) ; 

> 


/* send return nsg containing id */ 
pret->id = MAKE.ID (globTid, PUCE.HODE, indx) ; 
osgBuildSend (reqTid, globTid. MSG_COBrFIRM_REMOTE. 
(void •) prat, sizeof (REG.REMOTE), 

MF_STAHDARD) ; 
break ; 

case TRASS.IOOE: 

/* find local index */ 

if ((indx = find.trans ((char •)ps->act_naoe)) < 0 ) 

recinfo (globTid, "Could not find trans 'Xs' by naffleXn". 

ps->act_name) ; 

free (pret) ; 
return (ERROR) ; 

> 


/* send return msg containing id */ 
pret>>id = MAKE.ID (globTid, TRAHS.IODE, indx) ; 
nsgBuildSend (reqTid, globTid, NSG_CONFIRM.REMOTE, 
(void «) pret, sizeof (REG.REMOTE), 

KF.STASDARD) ; 
break ; 

} 

return (OK) ; 

} 


save.renote - save data from confirm remote msg 

STATUS save.remote (REG.REMOTE eps) 

{ 

int indx 


/* find place or transition */ 
switch (ps->type) 


78 


{ 

case PLACE.HODE: 

/* liiid local index */ 

if ((indx s 2ind_placa ((cliar «}ps->s7D.naffle}) < 0} 

{ 

recInlo(globTid, "Could not find place *%s' by nameVn", 

ps->s7m_n2UBe) ; 

return. (ERROR) ; 

} 


/* save id of remote place */ 
place Cindx] .id 3 pa->id : 
break ; 

case TRAVS.HGDE: 

/* find local index */ 

if ((indx = find_trans ((char ♦)ps->sym_naina)) < 0) 

{ 

recInfo(globTid, “Could not find trans ’%s* by naise\n“, 

ps->sym_name) ; 

return (ERROR) ; 

> 


/* save id of remote trans */ 
trans Cindx] . id 3 p ,i->id ; 
break ; 

} 

return (OK) ; 

> 


/**e*««****«««*****e*«**e«**«****«*«>***e*4>*«*««#*««**«**e***4>««*e««***e****4i4i4t4i 

save.update - save data from update register k reply vith nods id 

STATUS save.update (MSG,TYPE ♦m) 

{ 

int indx ; 

int id ; 

char ename ; 

UPDATES *pupd ; 

TID.TYPE myTid ; 

REG.REMOTE *ps ; 


/* parse message *! 

myTid = a->dest ; 

ps = (REG.REMOTE ♦) m->data ; 


/• find place or transition •/ 
switch (ps->type) 

case PLACE.HODE: 

/♦ find local index */ 

if ((indx - find„place ((char ♦)ps->act_aame)) < 0) 

{ 

recinfo (myTid, "Could not find place ''Li' by name\n", 

ps->act_name) ; 

return (ERROR) ; 

> 


/• save id for reply msg */ 
id 3 place [indx] .id ; 



/* add to npdata list */ 

pupd ~ (UPDATES •) malloc (sizsol (UPDATES)} ; 

pupd->n«xt 3 placflCindx] .update ; 

place [indz 3 .update 3 pupd ; 

pupd->tid 3 B''>source ; 

pupd->nuffi 3 ps->id ; 

break ; 

ease TRANS.HODE: 

/« find local index */ 

if ((indx 3 find^trans ((char *)ps->act naBe)} < 0 ) 

recinfo (myTid, "Could not find trans *%s' by name\n", 

ps->act.naae) ; 

return (ERROR) ; 

> 


/• save id for reply msg ♦/ 
id 3 trans [indx] .id ; 

/* add to update list */ 

pupd = (UPDATES *) malloc (sizeof (UPDATES)) ; 

pupd->next 3 trans [indx] .update ; 

trans [indx] .update = pupd ; 

pupd->tid 3 n->source ; 

pupd->nuD 3 ps->id ; 

pupd->vbich. 3 ps->wbich; 

/* recinfo (globTid, "Saved update for trans y,i, update * %d\n", 

trans [indx] . name , trans [indx] . update) ; */ 

break ; 

} 


/* send id in reply msg */ 

asgReply (m. (void *) id, MS_K 0 HE, MF_STAKDARD) ; 

return (OK) ; 

> 


/*333*33**333***e333********»*33*3************************#*#3(i*^***;*<iip****<,***<i 

initial.marking - send initial maurking to displays 

STATUS l^itiad_marking () 

ittt i ; 

UPDATES epu ; 

/* cheek each place */ 
for (i=C, i<nun,pl; i++) 

/* skip places with no marking, or no updates *i 
if ( (place [i] .orig_token 3s 0) j| 

C(pu 3 place[i] .update) == HULL)) 
continue ; 

/* loop through list */ 
while (pu) 

BsgBuildSend (pu->tid, globTid, MSG.SST.TQK, 

(void ♦) ((pu">num A OxOOOOffff) 
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I (pl&caCi] •orig.tukcn « 16 )), 

MS.HONE, Mr.STAKDARD) ; 

/• recinlo (globTid, ’•Initial markiMsX2i in placa 'Xs.Xs* on display Xx\n", 

place Ci] ‘Orig.token, ayNane, place CiJ ‘name, pu-'>tid) ; «/ 

pu ~ p’a->naxt ; 

> 

return (OK) 

> 


C.3 Xplay.c — Tests and Fires Transitions 

tiaclude <X11/Xlib.h> 

#includo <XH/Aiiti?..h> 

#include <Xll/Xos.h> 

#in:lude <Xll/Xatom.h> 

♦include <3tdio.b> 

♦include "ctos.h.’' 

♦include “btsLib.h" 


♦include ’‘Global _del.li‘' 
♦include 

♦include “Clobal.var-p" 
♦include 'Xolay.p*' 

extern char ♦ay.Maae ; 


* get_ready_treLns() 

* This routine selects the next transition to lire. It is 

* currently based on a pseudo-randou method, with some 

* consideration given to speed. It returns -1 il no 

* transitions are enabled. 

*/ 


io^t get_ready_trans(void) 

int current, ata,rt; 

start = randomO ’/, num.tr; 
current = start; 
do 

{ 

/* reclnlo(0, "7.s; Checking transition 7,i out ol 7,i\n”, 

myHaao, current, num_tr) \*/ 
il (traas_tok_enabled(current)) 

{il (trans_pre_enabled(current)) 
returr.( current) ; 

>; 

cuixenc ~ (c.uiTent+l)!(nun^tr; 

> 

uhile( current != start); 
ratum(-l); 

> 



* gat _r eady .hidden. tranaO 

* Thia routine selects the next bidden transition to tire. It is 

* currently based on a pseudO'-randoA ffletbod, eith none 

* consideration given to spaed. It returns -1 il no 

* transitions are enabled. 

*/ 

int get_ready.hiddeu_trans(void) 

int current, start; 

start = randomO V, aun.tr; 
current = start; 
do 

{ 

/♦ reclnto(0,"*/,s: Checking transition */,i out ot */.i\n", 

asyMane, current, nua.tr) ;*/ 
il (hiddenCcurrent) == TRUE) 

{il (trans.tok.anabledCcurrent)) 

{il (trans.pre.enabledCcurrent)) 
return (current) ; 

/; 

>; 

current s (current+l)'/.nun_tr; 

} 

vhile(current !~ start); 
retum(-l); 

} 


* hidden 0 

* This routine checks il the transition is not visible 

* on any display. 

*/ 


int hidden (int t.hua) 

{ 

UPDATES ep; 

p = transCt.num] .update; 
while (p != HULL) * 

{il ((p->«hich == T.START) 1 1 (p->which == T.BOTH) ) 

{/• recInlo(globTid, "Trans 7,s is visible\n'',transCt.num3 .name) ; 
re turn (FALSE) ; 

>; 

p = p->next; 


/* recInlo(globTid,"Trans '/.s is hidden with update: 7d\n", 

transCt.aua] .name, transCt.aua] .update) ; */ 

retum(TRUE) ; 

> 


♦ done.liringO 

* This routine checks il the lired transition should 

♦ complete the liring cycle iaaediately. Ch3.y blocking 

* transitions should not linish iaaediately. 

*/ 
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iut doae.f iringCint t.aun) 

< 

il (tranaCt.aun] .post.typa == F_R£M0TE) 
return(FALSE) ; 
else 

retiira(TRUE) : ' 

> 


* set.tokenO 

* This routine sets the number of tokens in the given place. 

*/ 


void set_token(int data) 

int p_num, num_tok: 

num.tok = (datak0xlfli0000)»16; 
p.num - datakOrflii; 

place Cp_num] .curr_token = num_tok; 

disp_set_tok(p_num) ; 


* sub.tokenO 

* This routine subtracts a number ol tokens to the given place. 
*/ 


void sub.tokenCint data) 

< 

int p.num, num.tok; 

num_tok = (data40xifll0000)»16; 
p.num - datakOxlfll; 

place Cp_nun] .curr_token -= nun_tok; 
if (place Cp_aum] .curr_token < 0) 
place Cp_auo] .curr.token = 0; 

disp_set_tok(p_num) ; 

/*****^***********«ii*v>ii*****4i:»^^«***e*ji*A<>*e***e»i»*»ee»eee»e»e*#ini»*<i*«»e4i 

* add_token() 

* This routii:.e adds a number of tokens to the given place. 

*/ 

void add_token(int data) 

< 

int p.num, num.tok; 

num.tok = (dataA0xffff0000)»16; 
p.num = datakOxffff; 

placeCp.num] .curr_token += num.tok; 
if (placeCp.num) .curr.token < 0) 
place Cp_num] .cuiT.token = 0; 


disp.set.tok (p.num) ; 
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> 

/********>p«************«******«<l*******<i**«****i********4il(l**i»41***lii»**:*l****J)l* 

* trans.pra_«aablad(} 

* Tbis routina chacks if both the tape raquirements aad 

* tha anabling function raquiraraants for firing a 

<* transition ara mat, as Ball as if the transition is 

* currently not firing. 

*/ 

int trans_pra_enabled(idt i) 

< 

int enabled * TRUE; 

if (transCi] .firing) 
ratum(FALSE); 

if (transCi] .tape.raq) 

{if (transCij .tapa_req != query _tape()) 
retumCFAlSE) ; 

>; 

if (transCi] .enable.func != NULL) 

{if (transCi] .anable.tTOa == F_LQCAL) 

enabled = (*trans{ij .anable.func) (transCi] . enabla.action. 

trans Ci] . enable.vax 

>; 


/* racInfoCglobTid, "Transition %d enabling: %d\n",i, enabled); */ 
retum(enabled) ; 

} 


* trans _tok_aaabled() 

* This routine checks if the token requirements for firing 

* a transition .are met. Both multiplicity and inhibitor arcs 

* are checked. 


♦/ 


int trans.tok_enabled(int i) 

{ 

struct Arc *arc_a; 

arc.a ~ transCi] .inp.arc; 
mhila(arc.a) 

{if (place Carc_a->place] .curr^token < aurc_a->mult) 
retum(FALSE) ; 
arc.a * arc_a->naxt; 

>; 


arc.a = transCi] . ish. arc; 
mhile (arc.a) 

{if (place Carc_a->place] . curr.token) 
retum(FALSE) ; 
arc.a » arc.a->next; 

>; 


retum(TRUE) ; 

} 





* lire.startO 

* Th.is routine starts the firing of a transition. It removes 

* tho appropriate tokens , absorbs any tape command and calls 

* the post.f unction. 

*/ 

void fire_start(int i) 

{struct Arc *arc_a; 

transCi] .firing = TRUE: 

arc.a - transCi] .inp.arc; 
ehile(arc_a) 

{placeCarc.a->place] .curr.token -= arc_a->mult; 
disp_set_tok(arc_a->place ) ; 
arc_a = arc_a->next; 

>; 

if (transCi] .tape_req) 

{absorb.tapeO ; 

}; 

if (transCi] .post.func) 

if (transCi] .post_type == F.LOCAL) 

(♦transCi] .post_func) (transCi] .post_action, transCi] .post_vax) ; 

else 

{(■^transCi] .post_func)(i, transCi] .post.tid, 

transCi] -post.action, transCi] .j. ~;;_fi^ta) ; 
recInfo(globTid."Xs: Executed remote post lunction\n",ii;yHame); 
>; 


disp.start.f ire(i) ; 

> 

* fire.endO 

* This routine ends the firing of a transition. It updates 

* the number of tokens in each output place. 

*/ 

void lire_end(int i) 

{ 

struct Arc earc.a; 

transCi] .firing = FALSE; 

arc.a = transCi] .out.arc; 

«hile(arc.a) 

{place Carc_a->place] .curr_token += arc_a->mult; 
disp_set_tok(arc_a->place) ; 
arc_a ' arc_a->next; 

}; 


disp_end_f ire(i) ; 


C.4 enable June, c — Loezd and Remote Enabling Functions 
#include <stdio.h> 
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tincluda "ctos.h" 

#isclxida "domLib.h" 

#iaclttd« "Clobal_d«f .b" 

#iaclude "Global.vax.p" 

*..*,*•.•*•*•*•«*.***••*****•*•******»**«***„« 

* kssoTtvi anabling.f unctions 0 

* B«loo is a bunch ot snail enabling lunetions. Done and 

* not.done and used lor looping 

•/ 

int gt(int action, int data) 

int Tar; 
char bullC20] : 

recPronptCglobTid. bull, "Enter greater than 7«d to lire: ", data); 
sscanl (ball , *’)ld" ,hvar } ; 
il (data < var) 
retum(TRUE) ; 
else 

retum(FALSE ) ; 

} 

int It (int action, int data) 

{ 

int var; 
char bullC20] ; 

recPrompt(globTid, bull, "Enter less than */«d to lire: ", data); 
sscanl (bull , "%d" ,ftvar ) ; 
il (data > var) 
return (TRUE) ; 
else 

retum(FALSE) ; 

} 

int done (int action, int data) 

il (action == 1) /* Return TRUE il variable = 0 ♦/ 

■Cil (read.var(data)) 
retum(FALSE) ; 
else 

return (TRUE) ; 

> 

else il (action =» -1) /* Return TRUE il variable != 0 */ 

•Cil (read_var(data)) 
retum(TRUE) ; 
else 

retum(FALSE) ; 

} 


int not_done(int action, int data) 

c 

il (!read_var(data)) 
return (FALSE) ; 
else 

return (TRUE) ; 
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int OQK.booKint action., int data) 

{ 

int •DOM.valua; 
cbar *str_ptr; 

str.ptr s gat.var.namevdata) : 

recInloCglobTid, ’'Executing DQN.bool for Xa. I hope you uanted toJ\n",atr_ptr); 

if ((DQM.value • (int *)objCopy(globTid, str.ptr)) HULL) 

{recIn2o(globTid. “ERROR: Object Xs not found in Data Object Manager\n“, 

str.ptr) ; 

return (FALSE) : 

>; 

if (action » 1) 

{if (*D0N_value) 
retum(TROE) ; 
else 

retum(FALSE) ; 

> 

else if (action == •!) 

{if (•DQM.value) 
retum(FALSE) ; 

else 

retum(TRUE) ; 

> 

> 

int DOK_done(int action, int data) 

{ 

int •OOH.value; 

if ((DQM.value = (int *) obj Copy (globT id, data)) == HULL) 

{recInfo(globTid, “ERROR: Object Xs not found in Data Object ManagerW, 

data); 

retum(FALSE) : 

>; 

if (action == 1) 

{if (*DQM. value) 
retu-n(FALSE) ; 

else 

retum(TRUE) ; 

> 

else if (action == -1) 

{if (•DQM.value) 
retum(TRUE) ; 

else 

retum(FALSE) ; 

> 

> 

/*4i«4i«**««*«**««««««*iti*«4i**4i«*«4i4i****4i«**«*»****«*:«4>**««**V«*«4i*4i4iik«V*«4t*« 

* enable.tableO 

* This array equates the synboli': namrs of the enabling 

* functions oith the actual function pointer . 

*/ 

«define KAX.EHA£:.E 6 

struct func. entry enable.tableO » 



<{DaM.booL , "DOM.bool**} , 
<D0M.don« , ‘‘DOM.doB***} , 
■{gt , “gr «at or .tthan'*} , 
{lt,"loss_than">, 
•Cdon«,"dono''>, 
{aot_doae,"ac6_done’*> 
>: 


« flAd.oaableO 

* This routiao roturas & poiater to the oa&bliag tuaction 

* specified bj its symbolic aame. 

*/ 

void of iad_aaable(aaffle) 
char oname ; 

{ 

iat i; 

if (!strcmp(nane,"0")) 
reti:ra(NULL) ; 

lor(i=0; i<MAX^EKABL2; i++) 

{if ( ! s' rcmpCaano , aaabla_tabla i]i] • idant_str) ) 
retura((void *)caable^tableCi3 .fuac_ptr); 

>: 


retura((void 

> 


C.5 posLfunc.c — Local and Remote Post Functions 

#iaclude <stdio.h> 

#iaclude **Global_def . h“ 
fiaclude “Global^var.p" 
tiaclude “donLib.h" 
tiacludc “coordTools.h" 

#iaclude "msg.h" 

/****««i******a*******a*aa******aw*aa*o*»**o>»*o*********o*oo*o*****o***o*** 

« Assorted post.foactioasO 

o Balov is a baack of small post fuactioas. laitialize aad 

* decramaat aro nsed for loopiag, but oaly have oa^ 

* variable to cork vith! Do aot use tao loops vith these.... 

*/ 

iat alive(iat actioa, iat data) 

{ 

recIafo(globTid, "Alive: VtdW, actioa): 

> 

iat live.iaitCiat actioa, iat data) 

{ 

char buffClO]; 
iat val ; 

/* recInfo(globTid,'*Iasida iaitializa\a") ; */ 
racPrompcCglobTid, buff, "Eater variable value: “); 
sscaaf (buff , “‘/,d" ,£val) ; 
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sav«_var(data, vad.); 

> 

int initializeCint action., int data) 

i 

save.varCdata, action) ; 

> 

int decrement (int action, int data) 

< 

int val; 

val s read_var(data) ; 
aave.varCdata, (val-action)); 

> 

int increment (int action, int data) 

< 

int val; 

val = read_var(data) ; 
save_var(data, (val+action) ) ; 

> 

int renameQBJ(int action, int data) 

{ 

char ♦str.ptr; 

str_ptr = (chair ♦)get_vau:_name(data) ; 
recInio(glohTid, ”0bj before rename^ *%s*\n”, str_ptr) ; 
ii (renaiffleQbjs(globTid, str.ptr) " ERROR) 

recInlo(globTid,'*renam30bjs Error: could not rename ’)(s’\n",str_ptr) ; 
else 

recInfo(globTid,"renameObjs successluUj renamed ’iCs ’\n",str_ptr) ; 

str_ptr = (char *)get_var_naae(data) ; 
recInlo(globTid,"Obj ailter renames •*/,s'\n", str_ptr) ; 


int duplicateOBJ(int action, int data) 
char ♦str.ptr; 

str_ptr = (char *)get_var_name(data) ; 
recInfo(globTid,"Obj before dup= ’%s*\n", str.ptr) ; 
if (daplicateCbjs(globTid, str.ptr) == ERROR) 

recInfo(globTid,”dupObjs Error; could not dup ’y,s'\n”,str_ptr) ; 
else 

recInlo(globTid,’'dttpObjs successfully dup'd *7,s’\n",str_ptr) ; 

str_ptr = (char *)get_var_name(data) ; 
recInfo(globTid,"Qbj after dup= ’*/.s'\n", str.ptr) ; 

> 

/^^*tiHl.tL^^lwm******«***************************m**m*******************m**^^m* 

* send_post_msg() 

* This routine builds and sends a message to the appropriate 

* post function server. 

*/ 

int send_post_msg(int indx, TID.TYPE dest.tid, int action, char *data) 




P0ST.DATA p_data; 


p.data.indx ~ indx', 
p.data. action = action; 
strcpy(p_data.data.obj , data) ; 


msgBaildSendCdest.tid , globTid, MSG_TRAHS_FIR£0 , (void *)ftp_data, 

si 2 eol(p_data) , MF.STAIIDAaD) ; 


} 


* post.tablaQ 

* Tbis array equates tbe symbolic names ol the post inaction 

* tith the actual function pointer. 

*/ 


#defiae HAX.POST 8 

struct func_entry post.tableQ = 

{{s end_post_msg , REMOTE_POST_FUNC}’ , 
■CrenameOB J , "renameObjs">, 

•Cdupl icat eOB J , “dupOb j s"} , 
■Cjd.ive,”aliva*‘>, 

{initialize , "initialize*'}, 
{live.init , “live_init"> , 
{decreraent , "decrement")' , 

•C increment , "increment"} 

}; 


ee«e****e*4>**«***««e**ee«**»*«*e***e^**«**4i****4c#***e«*e'*ee«e***« 

* lind_post() 

* This routine returns a pointer to the post function 

* specified by its symbolic name. 

*/ 

void *find_post(name) 
char *name; 

{ 

int i; 

if (!strcmp(name,"0")) 
retum(HULL) ; 

lor ( i=0 ; KKAX.PQST ; i++ ) 

{if ( ! strcmpCname.post^tableCi] .ident.str)) 
retumCCiroid *)pcst_tablaCi] -fuac.ptr); 

}; 


retum((void ♦)“!): 

} 

/* */ 

/* “rename" POST.LOCAL function •/ 

*/ 

STATUS renameObjs (TID.TYPE t, char *obj_string) 

{ 

# define MAX.OBJS 16 
int i, num_objs ; 
char •nameCMAX_OBJS] = {jrULL} ; 
chaur *objs ; 



objs - (char *) nalloc (strlen(obj_string)'i*l} ; 
scrcpy (objs, obj .string) ; 

if ((nun_objs = parseKanes (objs, naae}} =* ERROR) 

{ 

recInfo(t,"ren.ameObjs ERROR: could not parse *7,s'\n“, obj.string) ; 
free (objs) ; 
return (ERROR) ; 

> 

lor (i=0; i<nua_objs; i+=2) 

< 

il ( (name [i] "HULL) 1 1 (nameCi>l]"NULL)) 

{ 

recit.io(t ,"renameObjs ERROR: one ol the names cas nuU\n“) : 
Iree (objs) ; 
return (OK) ; 

} 

il (obj Rename (t, named], named'^1]) =- ERROR) 
free (objs) ; 

reclnlo(t,"rename0bjs ERROR: obj Rename returned errorXn") ; 
return (ERROR) ; 

> 

recInfo(t, "Successfully renamed 'Xs' as ’Xs*\n", nameCi], named+'.]) 


free (objs) ; 
return (OK) ; 
} 


/• */ 

/* "duplicate" PGST.LOCAL function •/ 

/» " ♦/ 

STATUS duplicateObj s (TID.TYPE t, char *obj.string) 

« define MAX.OBJS 16 
int i, num_objs ; 
char enameCMAX.OBJS] = {HULL} ; 
char *objs ; 

objs » (char •) malloc (strlen(obj_string)+l) ; 
strcpy (objs, obj. string) ; 

if ((num.objs = parseHames (objs, name)) == ERROR) 

recInfo(t,"duplicateObjs ERROR: could not parse *%s*\n", obj.string) 
free (objs) ; 
return (ERROR) ; 

> 

for (i=0; i<aum_ebjs; i+=2) 

{ 

if ((namaCi3==HUI.L) i 1 (nameCi+l]«HUlL)) 

{ 

recInfo(t,"duplicai.cObjs ERROR: one of the names «as nullXn") ; 
free (objs) ; 
return (OK) ; 

} 



if (objOupCt, nasiaCl]. aamfl[i-t-l]) as EiiRQR) 

{ 

recInfo(t ;”duplieataObjs ERROR: objOup returned error\n“) ; 
free (objs) ; 
return. (ERROR) ; 

> 

racInfo(t,**Sttccesslttlly duplicated ’5is* as ‘‘/.s'W*. 
naneCi]f naDeCi'*’!]} ; 

} 

free (objs) ; 
return (OK) ; 

} 


C.6 tape.c — Tape Commands 

^include <stdio.h> 

#include “Global_def.li" 
tfinclude "Global_var.p" 

* init_tape() 

* This routine initializes the tape list. You should use 

* clear.tapeO instead, as it free’s the memory used by 

* the tape elements as eell. 

*/ 

void init_tape(void) 

head = irULL; 
tail = NULL; 

> 


* append.tapeO 

* This routine appends a tape command onto the end of the 

* tape list. This is the standard method of adding a tape 

* command. 

*/ 


void append_tape(int command) 
struct tape.node *tmp; 

tmp ~ (struct tape.node *)malloc(sizeof (struct tape.node)); 

if (head) 

■Ctail->next = tmp; 
tail - tmp; 
tail->id = command; 
tail->next = NULL; 

} 

else 

{head ^ tmp; 
tail 3 head; 
tail->id = command; 
tail->next = NULL; 



} 


>: 


/**«*<»« «**«****««******4i*«4i4i**4i**4i«4i*«#** *********** 

* insart.tapeO 

* This routine inserts a tape command onto the head of the 

* tape list. This is not a standard use of the tape, but 

* provides for ^eater flexibility and exception handling. 

♦/ 

void insert_tape(int command) 

< 

struct tape.node «tmp; 

tmp = (struct tape.node *}malloc(sizeof (struct tape_node)); 
if (head) 

{trap->next = head; 
head = tmp; 
head->id = command; 

} 

else 

■(head * tmp; 
tail - head; 
head->id = command; 

>; 

> 

/^^^^*^L^*^t0*m*m**************m^ **************************9**^************* 

* query _tape() 

* This routine returns the command at the head of the tape, 

* vithout removing it. This is used to check if a transition's 

* tape requiznaent is satisfied for enabling. 

♦/ 

int quory.tape(void) 

< 

if (head) 

retum(head->id) ; 
else 

retum(-l) ; 

> 

/***«e«4ie*e*«*«******«***ee**«e««*«*****«««***««********«»««*««***«*«e***e 

* absorb.tapeO 

* This routine returns the command at the head of the tape, 

* then removes it from the list. 

*/ 

int absorb_tape(void) 

< 

struct tape.node *tmp; 
int id; 

if (head) 

■Cid = head->id; 
tmp a head; 
if (head «= tail) 
tail » SULL; 
head = head-xnext; 
free(tmp) ; 
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} 

als« 

id = -1; 

return (id) ; 

> 

* clear.tapeO 

* This routine removes all of the tape commands Irom the 

* the tape list, and sets the head and taiil pointers to BULL. 
*/ 

void cleax_tape(void) 

struct tape.node «tmpl,*tmp2; 

tmpl s head; 

Bhile(tmpl) 

{tmp2 = tmpl->next; 
free(tnpl) ; 
tmpl = tmp2; 


head - BULL; 
tail = HULL; 

> 

/•**********>***'»i*************»»#*e************Jiie*e***»*************>!i*»^***# 

* find_tape() 

* This routine returns the tape command id lor the given 

* symbolic name. II the name is not valid, -1 is returned. 

♦/ 

int lind_tape(char *nasie) 

{ 

int i; 

il (!strcmp(name,'*0'')) 
retuxn(HULL) ; 

lor( i=0 ; i<«AX_TAPE ; i++) 

■Cil ( !strcmp(name,tape_tableCi] .ident.str)) 
retumCtape.tableCi] .id) ; 

>; 

retum(-l) ; 

> 

* lind.tape.nameO 

* This routine returns the symbolic name ol the given 

* tape command id. II the id is not valid, HULL is retained. 

*/ 

char eiind_tape_name(int id) 
int i; 

lor(i=0 ; i<HAX,TAPS ; i++) 
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{if (id S3 tape.tablaCi] -id) 

retun(tapa_tabl«Ci] .idant.str) ; 

>: 


raturn(IHJLL) ; 

> 


* get.tapa.commandO 

* This routiaa queries the user lor a tape eonnaand, and 

* returns his selection. This is used £or testing purposes. 


int get_tape_comiaand(void) 
int select, i; 

lprint£(stderr,"\nTape Commands : \n" ) ; 

£ or ( i=0 : i<«AX_TAPE ; i++) 

£printf (stderr," */,d: y.s\n’‘,i,tape_table[i3.ident_str); 
£print£(stderr," */,d: No selaction\n'',i) ; 

£print£ (stderr, "\nSalection: *') ; 

iscainf (stdin,"*/.d",tselact) ; 

i£ (select == MAX.TAPE) 

•C£priat£ (stderr, "No select ion\n" ) ; 

retum(O) ; 

>: 

i£ ((select<0) 1 I (select>HAX_TAPE)) 

■C£print£ ( stderr, "'/.d is not a valid commandNn"); 
return(O ) ; 

>; 


£print£(stderr , "y,s\n" ,tape_table (select] . ident_str) ; 
retum(tape„table [select] .id) ; 


C.7 loadjntt.c — Loads the Petri Net Configuration File 

File: load.net. c 

Purpose: reads player and display configuration files 

Author: Joe Peck 

revised: Don Lefebvre 


Revised; 20 Aug '91 


♦include <Xll/nib.h> ^ 

♦include <X11/Xutil .h> 

♦include <Xll/Xos.h> 

♦include <Xll/Xatom.h> 

♦include <stdio.h> 

♦include <math.h> 
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«include "Global.daf .h“ 
#includa “Global.var .p‘* 
#include "racLib.h" 
#include '^ctos.h> 

extern ch.\r amyNane ; 


/♦ 

void *iind_enable 

void ♦lind.post 

int liad_place 

int lind.trans 

void do_error 

STATUS read_subnet_coniig 

STATUS read.display.coniig 

TID_TYPE lind.ooner 


luaction prototypes 

0 ; 

0 ; 

(cbar «aaffle) : 

(char *aame) ; 

(cbar *s) ; 

(FILE aiafile) ; 

(FILE *iQfile) ; 

(char vovaer) ; 




/4i^^^i^^0m**m*m*m********* ****************************************************** 

load.net - load configuration file 


RETURNS: OK or ERROR indicating success in reading config file 

INPUTS: char ♦net.conf ig_f ile - name of configuration file 

int type - type of config file (CF_PNET or CF_DISP) 

^t^^^i^^^^nH*********************************************************************/ 


STATUS 

load„aet (char *net_config_file, int type) 


FILE 

•fp: 

/* Temporary file pointer 

♦/ 

char 

f ile.naoeCMAXLINE] ; 

/* Actual file to open 

*/ 

int 

1 » J 1 k, 1 • 

/* Generic loop variables 

*/ 

char 

linebuf [MAXLINE] ; 

/* Generic buffer for line reads 

*/ 

char 

nameCHAXLINE] ; 

1* Used to read object names 

♦/ 

FILE 

•infile; 

/* File pointer to input file 

•/ 

char 

conusent (10] [HAXLINE] ; 

; /* Allow for ten lines of comments 

•/ 

struct 

Arc earc.a, *arc_b; 

/♦ Pointers to arc structures 

*/ 

struct 

Arc_poiat *arc,poiat. 

.a, *arc_point_b; 


int 

nun.points; 

/* Humber of points in an 2 irc 

*/ 

int 

nuB.arcs ; 

/• Number of arcs per type 

•/ 

int 

dummy; 

/♦ Generic variable 

*/ 

int num.read; 

/* Humber of items read by fscanf 

•/ 


/* Create config file name */ 
switch (type) 

i 

case CF.OISP; 

sprintf (file_name, '•*/,s.7.s‘‘, net.config_lile, ”<lisp’‘) ; 

breaR ; 

case CF.PNET: 

sprintf (file.name, ''7.s.7,s'*, aet_conf ig.file, "pnet") ; 
break ; 

default ; 

strcpy (file.name, net.config_file) ; 

> 


/• Open the config file •/ 


il (fp = lopen(lil«_najne,*'r")) 

< 

ini lie ~ Ip; 

else 

< 

sprintl (linebul, "Could not open conlig file 7«s". lile.nane) ; 
do.error (linebul) ; 
return (ERROR) ; 

> 

/* Interpret Comaent */ 

Bbile ( ( int ) Igets (linebul . MAILINE . ini ile ) ! ^EOF ) 

•Cil ( (linebul [0] == ' 1 ’)RR(lin*bul[l3 == *0*)4*(linebulC2] == *1’)) 
break; 

>; 

i = 0; 

Bhile ( ( int )lgats (comaent [i] , NAXLIHE , ini il«) ! =E0F) 

{il ((cooanentii] Co] == ’ I ')ftk(commentCi] [l] == ’\n*)) 

{comment [i] Co] ~ HULL; 
break; 

>; 

il (++i > 9) 
i = 9; 

>; 

/* Get tke number ol objects in the net */ 

lscanl(inlile,"l %d %d 7d %d */.d 7.d\n", Rnum^mp, hnuja_pl, tnum^rp, 
knoffl.tr, knum.^, knum.cs); 

/* Allocate Bork arrays •/ 

place s (struct Place *)malloc(num_pl«sizeol (struct Place)); 
trans » (struct Trans '*)aalloc(nua_tr*sizeol(struct Trans)); 
il (num.n^ >0) 

mpar = (struct MPar *)msLlloc(nuffl_apesizeol(struct MPar)); 
il (nna_rp >0) 

rpar = (struct RPar *)malloc(num_rp’*sizeol(struct RPar)); 

/* Process marking parameters */ 
lor (i=0;i<nua_mp;i++) 

{num_read - lscanl(inlile,“%s 7.d ‘/,1 71 7.d", name. taparCi] .num.token, 
kmparCi] .tag_z.in, kaparCi] •tag.y.in, kaparCi] .layer) ; 

il (num.read 5) 

do_error( "Missing inlormation lor marking parameter”); 

dummy ^ mpar Ci] .layer; /« Each layer is indicated by a bit mask */ 
mpar Ci] .layer = 1; 

Bhile (dummy) 

{mpar [i] .layer 1= l<<dummy; 

lscanl(inlila,"7d",kdufflmy) ; 

>; 


fflparCi].name = (char *)malloc(strlen(naiae)+i) ; 
8trcpy(ffipax[i] .name, name); 
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>j 

/*■ Process place inlormacioa */ 
lor (i=0;i<nua_pl;i++) 

{num.read * IscanlCinlile, "*/,s '/.d */.! 7,1 7.1 7.1 7.d*‘, name. 

*place[i] .orig_token, ftplaceCi] .x_loc_in, kplaceCi] .y_loc_in, 
ftplaceCi] .tag_x_in, AplaceCi] .tag_y_ia, AplaceCi] .layer) ; 

il CnuB.read 1=7) 

do^errorC "Missing inlormation lor place delinieion") ; 

dummy s placed] .layer; 
placed] .layer = 1; 
ithile (dummy) 

{place Ci] ■ layer |* l«dummy; 
lscanl(inlile,"7.d",&dummy) ; 

>; 

place [i] .name = (char *)malloc(strlen(name)+l) ; 
strcpy (place Ci] .name, name) ; 

placed] .curr_token = place [i] .orig„tokcn; 

il (placed] -orig.token < 0) /♦ decode place marking */ 

{place [i] .curr_token = mpeu: [-place [i] .orig.token - 1] .num_token; 
placed] .orig_token - placed] .curr .token; 

} i 


/• Process rate parameters */ 
lor (i=0;i<num.rp;i++) 

{num.read = lscanl(inlile,"7.s 7,1 7,1 7.1 7,d", name, krparCi] .lire.rate, 
fcrparCi] .tag_x_in, tepard] -tag.y.in, tepard] .layer) ; 

il (num.read !» &) 

do.error( "Hissing inlormation lor rate parameter"); 

dummy = rpar [i ] . layer ; 
rpard]. layer = 1; 
while (dummy) 

{rpard] .layer 1= l«dumny; 

1 s canl ( i'vf ile , "7,d" , tdummy ) ; 

>; 

rpard] .name = (char *)malloc(strlen(name)+l) ; 
strcpy (rpard] .name, name) ; 


/* Ignore groups carraptly •/ 

il (nuffl_gr) /* get rid ol last \n eilter previous line */ 

Iscanl (ini ilft,"\n") ; 
lor (i-0;i<num_gr;i++) 

lgeta(linebul,HAXLinE,inlile) ; 

/* Process Transition Inlormation */ 

lor (i=0;i<num.tr;i++) 

{num.read scan! (ini ile, "7,s 7.1 7.d 7,d 7,d 7.d 7.1 7.1 7.1 7.1 7.1 7.1 7.d", name, 
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A:trans[i] .fire. rata, tduoay, fttrans Ci] .kiad, 

Inuffl.axca, ktraas Ci] . orient , fttraasCi] .x.loc.in, 
ktransCi] .y.loc.in, ttraasCi] .tag.x_ia, ttraasCi] .tag_y_in, 
ktransCi] .rate.x.in, ktransCi] .rato_y_ia, ktraasCi] .layer) ; 

if (nuffl.read !» 13) 

do_error( "Missing iafornatioa for transition definition"); 


dumay » trans Ci] . layer ; 
trans Ci] . layer = 1 ; 
while (duaay) 

{trans Ci] .layer 1= l<<dummy; 
fscanf (infile, "Kd",tduany) ; 


trans Ci] .nane = (char •)malloc(strlen(na3ie)+l) ; 
strcpy(transCi] .name, nane); 

/* process input arc information */ 

for (j=0; j<num_arcs; j++) 

{arc.a = (struct Arc ♦)malloc(sizeof (struct Arc)); 
num.read = fscanf (iiifile,"*/,d Xd */.d Xd", ftarc_a->nult , Aarc_a->place , 

*num_points,tarc.a->layer) ; 


if (num.read != 4) 

do_error( "Hissing information for input arc definition"); 

dummy = arc_a->layer; 
arc.a->layer = 1; 
while (dummy) 

{arc_a->layer 1= l«dumny; 
fscanf (infile, "Xd",ftdummy) ; 

} > 


arc_a->type = IHPARC; 

arc_a->place -= 1 ; /• GreatSPN arrays start at 1 ... yuck ♦/ 

if (j==0) 

{trans Ci] .inp_ arc = arc.a; 
arc.b = arc.a; 

y 

el.«'j 

{arc_b“>next - zorc.a; 

arc.b = arc.a; 

>; 

for (k=0;k<num_points ;k++) 

{eirc.point.a o (struct Arc.point «)malloc(sizeof 

(struct Arc.point)); 
num.read = fscanf (inf ile,"Xf Xf\n", karc_point_a->x.in, 

karc.point.a->y.in) ; 

if (num.read != 2) 

do_errar("Hissing input arc location information"); 
if (k==0) 

{axc.b->axc.points * arc.point.a; 
arc.point.b = arc.point.a; 

else 

{arc.point .b->next - arc.point.a; 
arc.point.b = arc.point.a; 
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>: 


}; 

axc.a->next = HULL; 

>; 


/* process output arc iniomation «/ 
auffl_raad 3 Iscanf (inlile,"Z(l\n",fcl) ; 
il (nuD.read !> 1 ) 

do_error('‘Missjjig number of uutput arcs"); 
for (j*0; j<l; j++) 

{arc_a = (struct Arc *)nalloc(si 2 eof (struct Arc)); 
num_read = fscanf (inf ile,*‘*/.d 'lA */.d 7,d", *eirc_a->nult,lfarc_a“>place, 

Amum_point8,ftarc_a*>layar) ; 


if (num_read != 4) 

do_error( "Hissing information for output arc definition"); 

dummy = airc_a->layer; 
arc_a->layer = 1; 

Bhile (dummy) 

■Carc_a->layer I® l«dummy; 
fscanf (inf ile,"y.d" (ftduiamy) ; 

>; 

arc_a-->type * OUT ARC; 
arc_a->placa -= 1; 

if (j==0) 

■Ctrans[i3 .out_arc = arc_a; 
arc_b = axc^a; 

> 

else '* 

•Carc_b->aaxt = arc.a; 

arc^b = arc.a; 

>; 

for (k=0;k<nua_points ;k++) 

{arc.point.a = (struct Arc_poiat *)malloc(si 2 eof 

(struct Arc_point)); 
num_read = fscanf (infile, "*/,f */J\n", 4arc_point_a->x_in, 

4arc_poiat_a->y_ia) ; 

if (nun.read !» 2) 

d?_erTor("Hissing output arc location information"); 


if (k«0) 

{arc_b->arc_points = arc_point„a; 
arc_point_b = arc«point_a; 

> 

else 

{arc_point_b->next = art_point_a; 
arc.point.b = axc_point_a, 
y I 


>; 


>; 


/* process inhibitor arc information */ 
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aujo_r«ad » lscaal(infile,'*%d\ii'',»l) ; 

11 (nua.read !> 1) 

do_flZTor( "Missing numbsr ol inhibitor arcs"}; 
lor (j=0;j<l; j++) 

{arc.a > (struct Arc *)malloc(si 2 aol(s.nict Arc)); 
nua_reed » lscanl(ialils,"*/,d 5id 7,d */,d", Aarc_a->fflult,ftarc.a->piace, 

tnuffl.points , Aarc.a>>layar) ; 


11 (nua^read !« 4) 

do.arrorC "Missing inlomatlon lor inhibitor arc delinition") ; 

diuBiy » arc_a->layer; 
axc_a->layar » 1; 
ahila (dunay) 

{arc_a->layer 1= l«duaay; 
lscanl(inlila,"7,d",4diunay) ; 

}; 


arc_a->type = INHARC; 
arc_a->placa -* 1; 

il (j==0) 

<trans [i] . inh_arc » arc.a; 
arc_b = arc.a; 

} 

alsa 

{arc_b->naxt = arc.a; 

arc.b » arc.a; 

>; 

lor (k=0;k<nua_points ;k+-+) 

{arc.point.a s (struct Arc.point a)aalIoc(si:^8ol 

(struct Arc.point)): 

nua_read = lscanl(inlile,"7.1 %l\n", 4art_point_a->x_in, 

*arc_poiat„a->y_in) ; 

11 (num_real 2) 

do_error("Hissing inhibitor arc location Inlozmation") ; 


11 (k==0) 

■Carc_b->arc.points = arc.point.a; 
arc_point_b - arc_point_a; 

> 

alsa 

■Carc.pc. ut_b->naxt = arc_point_a; 

arc_poin^_b » arc.point_a; 

>: 


>; 



/* no? raad subnet interconnaction Inlo */ 
seitch (type) 

{ 

case CF.DISP; 

11 (raad.display.conlig (inlils) •= ERROR) 

closa (inlile) ; 
return (ERROR) ; 

} 
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break ; 

case CF.PIET: 

if (read_subaet_eonlig (inlile) == ERROR) 

close (i&lile) ; 
return (ERROR) ; 

y 

break ; 

> 

/* orapup and exit */ 
close (islile) ; 
return (OR) ; 


llnd.place - lind place number corresponding to name 
*****t^*************mm*******m*************************************************/ 
int lind_place (char *name) 

i 


int i; 


lor ( i=0 ; i<num_pl ; i++) 

il (!strcmp(name,placeCi] >name)) 
retum(i); 


retum(-l ) ; 

y 


lind.trans - lind transition number corresponding to name 

int 1 ind.tr ans (char *name) 

{ 

int i; - 


lcr( i=0 ; i<nua_tr ; i++) 

il (!strcmp(name,transCi] .name)) 
retum(i) ; 


retum(-l) ; 

> 


do.error - print error string ; 

»0m**m**mm*m*m*******m*‘**********m**9*****************m*******’^***************/ 
void do.error (char *s) 

{ 

recZnlo(globTid, "ERROR: %s\n",s) ; 


read_subnet_conlig - read configuration ol subnet player 
read_subnet_conlig (FILE einlile) 


STATUS 
{char 
char 
char 
char 


linebttl 

ick 

sym.naiao 

bull 


[255] 

[IS] [255] ; 
[40] ; 

[40] ; 
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char lunc.naae [40] ; 

char loc [40] ; 

char omer [40] ; 

char aaffltt [40] ; 

char actioa [40] ; 

char data [255] ; 

iat iadx ; 

iat i, ioax; 

void *ptr; 

/« raad reoaiaiag liaes oi file */ 

vhile (fgsts (liaebuf, MAXLIHE, ialile) !« HULL) 

imax = sscaaf (liaebuf . '*y.s */.s */.s 7.s 7.s %s 7,s Xs Xs %s Xs Xs Xs 7,s 7,s“, 
ick[0] ,i^k[l] ,ick[2] ,ick[3] ,ick[4] ,ick[S] ,ick[6] ,ick[7] , 
ick[8] ,ick[9] .ickClO] .ick[ll] ,ick[12] ,ick[l3] .ick[i4]}; 


/* process PLACE liae */ 

if (! stracasecmp (ick[0], "PLACE", 5)) 

3trcp7(syin_BajBe,ickCi++] ) ; 
strcpyCloc, ickCi*+] ) ; 

if (! stracasecmp (loc, “REMOTE", 5)) 

i 

if ((iadx = fiad_place (sym.aame)) < 0) 

{ 

recI:ifo (globTid, “Could aot find place ‘7,s‘ by aameNa", 
sym.aaae) ; 
coatiaue ; 

> 

place [iadx] . act _aama = (char *)malloc(strlea(ick[i])-fl) ; 
strcpy (place [iadx] . act.aaae, ick[i ++] ) ; 
strcpy(ovner ,ick[i++] ) ; 
place [iadx] . ovaer = fiad.ocaer (owaer) ; 

> 

else 

if ((iadx = fiad_place (syn.aame)) < 0) 

reclafo (globTid, "Could aot fiad place 'Xs* by aame\a”, 
sym.aaae) ; 
coatiaue ; 

} 

place [iadx] .outer = globTid ; 

plate [iadx] .id = MAKE.ID (globTid, PLACE.NODE, iadx) ; 

place [iadx] .act.naae = (char ♦)malloc(strlea(sym_aaffle)+l) ; 
strcpy (place [iadx] . act.aaae , sya_acune ) ; 

> 

> 

/♦ process TRAMS liae */ 

else if (! stracasecmp (ickCO], “TRAMS", 5)) 

{strcpy (sym.aaae, ick[i++] ) ; 

if ((iadx “ fiad.traas (sym.aaae)) < 0) 

{ 

reclafo (globTid, "Could aot fiad traas ’*/.s* by aam«\a", 


coatinae ; 


sym^aans) ; 


> 

trans [indx] . ooii«r > globTld ; 

trans Cindx] . id « MAKE.IO (globTid, TRANS.NQDE, indz) ; 
trans Cindx] . aaabla.typa = F.IONE; 
transCindx] .post. type 3 f.HONE; 
transCindx] .update = SUU.,* 


while (Kiffiax) 

{strcpy (bul f , ick Ci-H-] ) ; 


ii (!strncasec 3 tp(bufl , "ENABLE.LQCAL" , 12)) 

{ 

traas [ittdx] . enable.type = F.LQCAL; 
strcpy(iuac.name,ickCi++] ) : 
ptr - f ind_enable(iauc.nane) ; 
il ((iat)ptr - 1 ) 

■Crecinlo (globTid, "Could not find enabling ", 

"function /is\n", func.naiae); 

continue; 

}; 

recInfo(globTid, "Found enabling function /Cs\n",func_name) ; 

transCindiJ.enable.func = ptr; 


strcpy ( act ion , ick Ci++] ) ; 

transCindx] .enable.action = atoi(action) ; 

strcpy (data, ick Ci++] ) ; 

if ((transCindx] . enable, var = find, variable (data)) < 0 ) 
recInfo(globTid, "Insufficient storage for *%s'\n". 


else if (! stmcasecmp(buff , "POST.LOCAL" , 10)) 

{ 

transCindx] .post.type = F.LOCAL; 
strcpy (fxinc.naae , ick Ci++] ) ; 
ptr = f ind.post(func.name) ; 
if ((int)ptr == -1) 

{reclnfo (globTid, "Could not find post function 5(s\n" 
f unc.nane) ; 


continue; 

>; 

transCindx] .post.func = ptr; 


strcpy (act ion, ickCi++] ) ; 

transCindx] .post.act ion = atoi(action) ; 

strcpy (data, ickCi++] ) ; 

if ((transCindx] .post _var = find.variable(data) ) < 0 ) 
recinfo (globTid, "Insufficient storage for ’7,s’\n", 

data) ; 


> 

else if (! stmcasecmp(buff , "POST.REMOTE" , 11)) 

i 

transCindx] .post.type = F.REMQTE; 

transCindx] .post.func = f ind_post(REH0TE_P0ST_FUNC) ; 
if ((int)ptr == - 1 ) 

{recinfo (globTid, "Could not find post function */,s\n" 
REHOTE.POST.FUSC) ; 


continue; 

}; 



strcpy(iunc_najne,ickCi++] ) : 

trails Ciadx] .post.t id a fiiid_oHner(iunc_iiaiae); 

strcpy(action,ickCi++]) ; 

transCindx] .post.actioa - acoi (action) ; 

strcpyCdata, ick[i++] ) ; 

transCindx] .post.data » (ckar *)malloc(strleii(data)-*-l) ; 
strcpy(transCindx] .post.data, data); 

>; 


> 

> 

/* process SUBNET line */ 
else il (■ stmcasecmp (ickCO] , "SUBNET". S)) 
strcpy (name , ick Ci++] ) ; 

net_name = (char *) malloc (strlen(name)+l) ; 
strcpv (net.name, name) ; 

} 

/* ignor.e all other lines •/ 

else recInfo(globTid, "Unrecognized parameter in conlig lile: i(s\n". 

buif) ; 


return (OK) ; 

> 


read_display_conf ig - read configuration of subnet display 


STATUS read_display_config (FILE ♦infile) 
< 


char 

linebuf 

[MAILINE] 

char 

ick 

[15] [40] ; 

char 

buff 

[40] ; 

char 

sym_name 

[40] ; 

char 

act .name 

[40] ; 

char 

disp 

[40] ; 

char 

ovner 

[40] ; 

int 

indx ; 


int 

i, imax; 


TID.TYPE 

tid ; 



/♦ read remaining lines of file ♦/ 

Bhile (fgets (linebuf , MAILINE, infile) >= NULL) 

imax = sscanf (linebuf , "‘/.s ‘/.s 'l,s V.s '/.s */.s *;(s */.s %s 7.s 7.s '/,s V.s 7s 7, 
ickCO] .ickCl] ,ickC2) ,ick[3] ,ick[4] .ickCS] ,ick[6] .ickCT] , 
ickCS] ,ickC9] .ickClO] , ick [11] ,ickCl2] ,ick[13] , ick [14] ) ; 

i=l; 


/* process PLACE line •/ 

if (! stmcasecmp (ickCO], "PLACE", 5)) 
■Cstrcpy(sym_name,ick[i++] ) ; 

if ((Indx = lind_place (sya.name)) >- 0) 
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{ 

place Cindx] .act_naiae = (char *)malloc(strlen(iclcCi] )+l) 
strcpj (place Cindx] .act_aame,ickCi'*"'’] ) : 
strcpy(oroer,ickCi++] ) ; 
tid =» lind_oBncr (otmer) : 
place CiadxJ . owner s tid ; 

> 

else 

recZnfo (globTid, “Could not lind place ‘7.s’ by naneW, 

sym_najne) ; 

> 


A process TRAHS line */ 

else ii (! stmcasecap (ick[0] , “TRANS’*, 5)) 

•Cstrcpy(sym_naoe,ickCi++] ) ; 

strcpy (buil , ick Ci++] ) ; 

il (1 stmcasecmp (buff, “SINGLE", 6)) 

{if ((indx = lind_trans (sym_naae)) >= 0) 

{trans Ciadx] .act_nane = (char *)malloc(strlen(ick[i] )+l) ; 
strcpy(trans [indx] . act_naae , ick [i++] ) ; 
strcpy (owner , ick [i++] ) ; 
tid = lind_owner (owner) ; 
trans Cindx] . owner = tid ; 

> 

else 

recinfo (globTid, "Could not find trans ’‘/.s’ by naneXn", 


else if (! stmcasecmp (buff, “DQUBLE", €)) 

{if ((indx = find.trans (syn.name)) >= 0) 

{trans [indx] .act _name = (char *)malloc(strlen(ickCi] )+l) ; 
strcpy (trans [indx] . act_name, ick[i++] ) ; 
strcpy (owner, ick [i++] ) ; 
tid = find.owner (owner) ; 
trans Cindx] .owner w tid ; 


trans Cindx] . act_end_nane = (chsir *)nalloc(strlen(ick[i] )+l) ; 
strcpy (trans Cindx] .act_end_name,ickCi++] ) ; 
strcpy (owner, ick Ci++] ) ; 
tid * find_owner (owner) ; 
trans Cindx] . end.owner > tid ; 

recinfo (globTid, "Trans ‘/.s is split: ‘/.s , 7,s \n“, trans Cindx] .name, 
trans Cindx] . act .name , trans Cindx] . act.end.name) ; 

> 


else 

recinfo (globTid, “Could not find trans 


} 


}; 


’*/.s’ by name\n", 
sym.name) ; 


I* process DISPLAY line •/ 

else if (! stmcasecmp (ickCO] , "DISPLAY", 7)) 

{net.name = (char *) malloc (strlen(ickCi])+l) ; 
strcpy (net.name, ickCi++]) ; 
if (i < imax) 

{playTid = find.owner(ick[i]) ; 

} 
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playTid = globTid; /* Daiault action */ 


/• ignore all other lines •/ 


return (OK) ; 

> 


find.ovner > find tid of oraer of place or transition 

TID.TYPE find.owner (char *otrner) 

{ 

/* 

oant to add “smarter" function than remembers already found ooners 

•/ 

ret;im (msgTidQuery (globTid, owner)) ; 

> 


C.8 msgs.c — Sends Various Messages 

#include <X11/Xlib.h> 

#include <X11/Xutil.h> 

#include <Xll/Xos.h> 

#include <Xll/Xatom.h> 

#include <stdio.h> 

#include <ctos.h> 
tinclude <btsLib.h> 

#include "Global.def .h" 

♦include "msg.h" 

♦include "Global. var.p" 

extern TID.TYPE toTid; 
extern char emylTame ; 

♦define FIRE.RATE (1) 

* disp.set.tokO 

* This routine builds and sends a message to the display 

* indicating the new contents of a place. 

*/ 

void disp.set.tok (int p.num) 

{ 

UPDATES *pu ; 

MSG.TYPE msg ; 

/* for local place, send msgs to displays */ 
if (place Cp.num] . owner == globTid) 

/* get start of updates list ♦/ 
if ((pu = place Cp_aum] .update) == SULL) 
return ; 
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/* build message to displajs */ 

msgBuild (tesg, 0, globTid, MSG.SET.TOK, NULL, HS.NONE, MF^STANDARD) ; 

/• loop through list */ 
chile (pu) 

< 

fflsg.dest - pu->tid ; 

msg.data = (void •) ((pu->Bua k OxOOOOlfff) 

I (placaCp.nua] .curr.token « 16)) ; 

msgSead (ftosg) ; 

/* 

recinfo (globTid. "Set tokens=7.2i in place *7,s.*/,s’ on display 7.x\n", 
place Cp.nuffl] .curr.token, myName, place Cp.nujQ] .name, 
pu->tid) ; 

*/ 

pu = pu->next ; 

> 

/* recinlo (globTid, "Set tokens=72i in place ’7.s.7s’\n", 

place Cp_nmn] .curr.t ok en, myName, place[p_nunG .name) ; ♦/ 


/* for remote place, send msg to owning player ♦/ 
else 

i 

msgBuildSend (place Cp_num] . owner , globTid, MSG_ADD_TQKEN, 

(void *) ( ((FIRE.RATE « 16) k OxiiltOOOO) 

I ITOEX.FROM.ID (place Cp.aum] .id) ), 

MS.HONE, MF.STANDARD) ; 

/* recliifo (globTid, "7,s: Add token to remote place ’5(s’ in net 5(x\n", 

myName, place Cp_num] .name, place Cp_aum] .owner) ; ♦/ 

> 

* disp_start_iire() 

* This routine builds and lends a message to the display 

* indicating that a transition has begun firing. 

*/ 

void disp_start_lire (int t_num) 

{ 

UPDATES *pu ; 

MSG^TYPE msg ; 

/* get start oY updates list •/ 
il ((pu = transCt^num] .update) -- NULL) 
return ; 

/* build message to displays */ 

msgBuild (tasg. 0, globTid, MSG.START.TRANS , NULL. MS.NONE, MF.STANDARD) ; 

/* loop through list */ 
while (pu) 

if ( (pu->which)k(T_START) ) 

{ 

msg.dest = pu->tid ; 
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nsg.dac& = (void *) pu->num ; 
msgSand (ftmsg) ; 

/• 

raclnlo (gl&bTid, “Start firing trans ’’/.s.Xs’ on display %x\n“, 
nyRane, trans Ct.num] .name, pu->tid) ; 

•/ 

}; 

pu = pn->next ; 

> 

raclnlo (globTid, “Start liring trans '%s.%s'\n“, myfame, trans [t.nom] .name); 

> 

* disp^end.lireO 

* This routine builds and sends a message to the display 

* indicating that a transition has ended firing. 

♦/ 

void disp_end_fire (int t_nua) 

UPDATES *pu ; 

MSG.TYPE msg ; 

/* gat start of updates list ♦/ 
if ((pu = trans Ct_num3 .update) == HULL) 
return ; 

/* build message to displays */ 

msgBuild (tesg. 0, globTid, HSG.EHD.TEAHS , HULL, HS.HOHE, MF_STAHDAHD) ; 

/* loop through list */ 
while (pu) 

{ 

if ((pu->which)h(T_EMD)) 

i 

msg.dast = pu->tid ; 

msg. data = (void *) pu->num ; 

msgSend (ftmsg) ; 

/* 

recinfo (globTid, “End firing trans on display */,x\n“, 

myHame, trans Ct.num] .name, pu->tid) ; 

♦/ 

>: 

pu = pu->next ; 

> 

recinfo (globTid, “End firing trails ’/(s./Cs'\n'', myHame. trans[t.num].name): 

> 


C.9 var.man.c — Manages the Variables for Local Functions 

#include “Global.def .h“ 

struct var.entry var.tableCHAX.VAE] ; 

int f ind.variable(char *name) 
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{ 

int i; 
i » 0; 

vliile ( ( i<MAX.VAR)ftt( var .table Ci] • ident.str) } 
{if ( ! strcmp(name,var_tableCi3 • ident.str) ) 
retum(i) ; 
i++; 

>; 


if (KMAX.VAR) 

{var_table[i3 .ident.str ^ (cbar *)fflalloc(stzlenCnane)'^l) ; 
strcp 7 (var .table Ci] .ident.str,naae) ; 
retum(i) ; 

}; 


retum(-i); 

> 

int read.varCint index) 

{ 

return (var.t able [index] .value) ; 

> 

void save.varCint index, int value) 

{ 

var.table [index] .value s value: 

> 

char ♦get.var.nameCint index) 
retumC var.table [index] . ident.str) : 

> 




APPENDIX D 
Display Software 


D.l Makefile — The Display Makefile 

# lor test ol UHIX version ol CTOS 

IHCl = /hOffle/page/MCS/src/lib/btsLib 
ZMC2 3 /home/page/MCS/src/lib/msgLib 
INC3 = /home/page/MCS/sre/lib/ctosSbell 
IHC4 * /usr2/testbed/CIRSSE/installed/UNIX/h 
IHC5 3 /home/lef ebvre/DEMOS/pnets/player 
INC6 3 /home/page/MCS/src/lib/recLib 
INC7 3 /hoffle/lelebvre/unix/ctos/domLib 

CFLAGS 3 -0 -Wretum-type -Wunused -Uswitch -Wcoaaent 

-Wshadov -Wpointer-arith -DKAKE_SUH4 -I$(mci) -I$(INC2) 
-I$(INC3) -I$(IMC4) -I$(IHCS) -I$(IHC6) -I$(INC7) -DQS.UHIX 

BIHDIR 3 /homa/page/MCS/bin/suii4/ 

BTSLIB 3 $(BINDIR)btsErr.o $(BINDZR)btsSem.o $(BlNOXR)btsGlobals.o 
$ (BINDIR) DSgLib . o $ (BIin)IR)msgBCMem . o 
PLAYDIR 3 /home/lelebvre/DEHOS/paets/player/ 

RECOIR 3 /home/page/HCS/bin/san4/ 

# List ol targets . . . 
all : disp.eh 


# E.H. Tasks.. . 

disp.eb: disp.eh.o Xsetup.o Xdrav.o manip.net.o ffionitor.o Xinter.o \ 

$ (PLAYDIR) load.net . o $ (PLAYDIR ) var.man . o 
gcc $(CFLAGS) -o disp.eh disp.eh.o Xsetup.o Xdrav.o manip_net.o \ 
aonitor.o Xinter.o $(PLAYDIR)tape.o $ (PLAYDIR) load.net. o \ 

$(RECDIR)recLib.o $(PUYDIR)enabla.laac.o $(PLAYDIR)post_lunc.o \ 
$(PLAYDIR)var.nan.o S(BTSLIB) $(BIIDIR)ctosShell.o \ 
-L/h.ome/lelebvre/DEMOS/demol 'L/bone/lelebvre/uniz/ctos/domLib \ 
-Icoord -Idom -1X11 -lo 

disp.eh.o: disp.eh. c $(PLAYDIR)Global_del.h 
gcc -c SCCFLAGS) disp.eh. c -o disp.eh.o 

Xsetup.o; Xsetup.c $(PLAYOIR)Globea_del.h 
gcc -c $(CFLAGS) Xsetup.c -o Xsetup.o 

Xdraa.o: Xdrav.c $ (PLAYDIR) Global .del. h 
gcc -c $( CFLAGS) Xdrav.c -o Xdraa.o 

aanip.net. o: manip.net.c $(PLAYDIR)Global_del.h 
gcc -c $(CFLAGS) manip.net.c -o manip.net.c 


aonitor.o: aonitor.c 

gcc -c $(CFLAGS) monitor. c -o monitor. o 


no 



Ill 


Xintar.o: Xinter.c $(PLAYDIR)GlQbal_def .h 
gcc -c $(CFLAGS) Xintar.c -o Xintar.o 


D.2 disp.eh.c — The Display Event Handler 

Fila: disp.ab.c 

Purpose: "Petri Nat Display" avant handler displays portions oi net 

Author: Joe Peck 

revised: Don Lefebvra 


Revised; 20 Aug'91 

lfm***m*mm***m*m*******m*********************^***m*****m***m******************m/ 

/* — include liles */ 

•include <X11/Xlib.h> 

•include <Xll/Xutil .h> 

•include <Xll/Xos.h> 

•include <Xll/Xatom.h> 

•include <stdio.h> 

•include <sign^ll.h> 

•include <cto$.h> 

•include <btsLib.h> 

•include <recLib.h> 


•include "nsg.h" 
•include "Global.def .h" 
•include "Global.var.h" 


/♦ global variables — — — >*/ 

char root_nameC200] ; 

char bull [2003; 

char emyNaffie ; 

char coniig.lile [HAXLINE] ; 

/* lunction prototypes — */ 

STATUS load.net (char 4>net.coniig_iile, int type) ; 

STATUS register .updates () ; 

void printPTinfo () ; 

void go.monitor () ; 

MyTaisk(disp.eh) 


/eee**«e-»*e*e**«*e4‘««*e«*«*«*ee«**e««*e«e*«««***e*««««****>i>*eee««*****eeee***e* 

disp.eh - subnet display for Petri Net 

SYK30LIC NAME: (used to configure net) 

RETURNS: 0 indicating processing complete 

PARAMETERS: TID.TYPE myTid - task id of event handler 

HSG.TYPE *msg - pointer to received message 

int disp_ah(TID.TYPE myTid, MSG.TYPE ♦msg) 
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static BOOL ready » FALSE ; 
static int proc.id; 
int k, 1; 

char databultClO] ; 
svitch(DSg-'>conmaii.d) 

•c 

case MSG .TASK. ARCS: 

strcpy (boil , msg->data; ; 
break; 


case MSG.PIHIT: 

globTid = myTid; 

nyKame » msgHyTaskName (myTid) ; 

sscanfCbull ,*'%s %s", root.name. display_aame ) ; 

/* read display config file */ 

if (load.net (root.aame, CF_DISP) -= ERROR) 

< 

reclnfo (myTid, "Unable to load config file *y,s*.disp", 
root_name) ; 
jnsgAckAINlT (myTid) ; 

msgApplicationExit (myTid) ; 

reclnfo (myTid "OISP: Loaded net *)(s.disp’\n", root_name); 

/* create X eindoe • , 

Xinit (myHame, HULL, 0) ; 

reclnfo (myTid, "%s Initialized sindoaW, myMame) ; 

/• initiailiza variables ♦/ 
visible.layer = Oxffff; 
tags.on s 1; 
scale = 1.0; 
offset.! =0.0; 
offset.y = 0.0; 


/♦ scale the net */ 

rescale.net (scale, offset.z, offset.y); 

/* reclnfo (myTid, "Xs Scaled net\n", myHame) ; •/ 
sleep(2); 

/• display the net */ 
drae.ehole.net 0 ; 

reclnfo (myTid, "y,s Displayeo uet\n", myHame) ; 

/* ready » TRUE ; */ 

break ; 


case MSG.AIHIT: 

register.updates () ; 

/« Fork off the process to monitor input */ 
proc.id = forkO; 

if (proc.id »* 0) /• monitor process •/ 

gojnonitorO ; 
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caaa 

/• 


case 


/* 


/♦ 


/♦ 


/* 


/* 


/♦ 


break : 


MSG.AEXEC: 

recinfo (myTid, '7.s Received AEXECW, myNasie) ; 
printPTinfo () ; */ 

break ; 


MSG.DRAW^WHOLE.IfET: 

recinfo (myTid. "*/.s Received DRAV.WHOLE.RETW , nyName) ; 

drav_vliole_net() » 

break; 


case MSG_SIT_OM_HAMDS: 

recinfo (myTid, *7.s Received SIT.ON.BARDSXn'* . myRsuae) ; 

sleep(S); 

break; 


case KSG.SET.TOK: 

recinfo (myTid, "'/.s Received SET_TOK\n'*, myName) ; */ 
8et_token(msg->source, (int)msg->data) ; 
break; 


case MSG.START.TRAHS : 

recinfo (myTid, "/.s Received START_TRARS\n'* , myRane) ; */ 
mark_trans(msg">source, (int)msg->data) ; 
break; 


case MSG.ERD.TRARS: 

recinfo (myTid, "%s Received ERD_TRARS\n” , oyRaae) ; ♦/ 
Qnmark_trans(asg->source, (int)msg->data) ; 
break; 


case MSC.TOGGLE.TAGS: 

recinfo (myTid, Received TQGGLE.TAGSXn" , myHaae) ; •/ 
tags^on *= 1; 
draB_vhole_net() ; 
break; 


case MSG.VISIBLE: 

recinfo (myTid, "%s Received VISIBLENn'*, myRame) ; •/ 
visible„layer = (int)msg->data; 
draB_vhole_net() ; 
break; 


case MSG.SHIFT.DISPLAY: 

recinfo (myTid, *'*/.s Received SHIFT_DISPLAY\n", myRame) ; */ 
offset_x += (* j -it)H0RI_SHIFT((int)m8g->data) ; 
offset.y += *1; it)VERT_SHIFT((int)msg->data) ; 

rescale_net(scAle, offset_x, offset.y); 
drav.Bhole.netO ; 
break: 



case HSG.CBAHGE.SCALE; 

raclnio (nyTid, "7.S Received CHAHGE_SCAl.E\n” , rnyHaae) ; •/ 
scale ♦» (float )Uia';)(msg->data)eSCALE_FACTOR); 
if (scale <B 0.0} 
scale • 0.1; 

reseale_net( scale, offset.x, ollset.y); 

dra9_Bh0le.net 0 : 

break; 


case NSG.SELECT.PUCE: 

reclafo (nyTid, ”7.s Received SELECT.PLACEXn” , nyHane) ; 

1 - GET.ZVDEX((iat)nsg->daLta); 
s«itch(GET_BUTTON((int)msg->data) ) 

{case 1; 

recZnfo(globTid, "Should add a tokenNn"); 
nsgBuildSend(placeCl] .ouner. myTid. 

HSG.ADD.TOKES, 

(void *) ((INDEX_fROM.ID(placeCl] .id) 
k OxOOOOlllf) I (1 « 16)), 

MS.MOHE, KF.STANDARD); 
break: 
case 2: 

recPronpt (myTid, databulf," Place >(s: Enter token quantity: 
place Cll .name) ; 
if (sscanf (databuff ,''7.d’‘,kk}) 
if (k>»0) 

msgBuildSend(placoCl] <o9ner, myTid, 

MSG.SET.TOK, 

(void •) ((IHDEX_FRQM.ID(placeCl] .id) 
k OxOOOOffff) 1 (k « 16)), 

MS.NOBE, MF.STABDARD) ; 

break; 
case 3; 

recInfo(globTid, "Should subtract a tokenXn"); 
msgBuildSend(place Cl] .owner, myTid, 

MSG.SUB.TOKEH, 

(void •) ((IHDEX_FROH_ID(placeCll.id) 
k OxOOOOffff) I (1 « 16)), 

MS_H0IE. MF.STA5DAE0) ; 
break; 

}; 

break; 

case MSG_SELECT.TRAIS: 

reclnfo (nyTid, "%s Received SEL£CT_TRANS\n" , myBaae) ; 

1 » GET_IIDEI((int)nsg->data); 
if (node « SIMGLE.STEP) 

{msg3nildSend(trans[l] .owner, nyTid, 

MSG_CHK_FIRE_TRAHS , 

(void •)IBDEX.FROM_ID(transCl] .id) . 

MS_I0ME, MF.STAHDARD); 

>; 

break; 

case MSG_SET_MODE; 

reclnfo (nyTid, "Ks Received SET_M0DE\n“, nyHama) ; 

node a (int)nsg->data; 

break; 
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case MSG.PTERM: 

/♦ reclnfo (myTid, “/is Received PTERM\n", mySane) ; */ 

kill(prcc_id,SIGKILL) ; 
break; 

> 

/♦ until X BindoB refresh Borks» redraB everything ♦/ 
if (ready == TRUE) 

/* draB_Bhole.net () ; */ 

usleep(SOO) ; 

}; 


return (msgOefaoltProc (nyTid. msg}} ; 


printPTinfo - print place 4 transition information 

void printPTinfo () 

{ 

int i ; 


if (Istrncasecmp (myName, "DISP.A", 6)) 
sleep (3) ; 

else if ( '.stmcasecap (myName, "OISP_B“, 6)) 
sleep (4) ; 

else if ('.stmcasecap (myName, "DISP.C", 6)) 
sleep (S) ; 

reclnfo (globTid, "\nHet Name: Xs\n", myName) ; 

reclnfo (globTid, "PLACES Cy.ij\n", nnm.pl) ; 

for (i=0; i<num_pl; i++) 

{ 

reclnfo (globTid, "\t7,6s %8x %4x \n", place [i] .name, 
place Ci3 . id , place Ci] . OBner ) : 

> 

reclnfo (globTid, "TRANSITIONS C7,i]\n", ntur.tr) ; 

for (i=0; i<nnm.tr; i++) 

{ 

reclnfo (globTid, "\tX6s */(8x %4x \n", transCi] -name, 
trans [i] . id , trans Ci] . oBner ) ; 

> 


> 


register.updates - sends request msgs to register display updates 

STATUS register.updates () 

int i ; 

REG.RE.MOTE *ps ; 

/* send msg for each place */ 
for (i=0; Knum.pl; i++) 
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ps = (REG.REMOTE *) nalloc (sizeof (REG_REMOTE) ) ; 
strcpy (p8->syB_n.ana, plav.«Ci] -naffla) ; 
strcpy (ps->act_nama, place Ci] .act.nama) ; 
ps->Cypa = PLACE_NODE ; 
ps“>id » i : 

placaCi]-id - msgBuildSand (placaCil .09nar , globTid. KSG.REGISTER.UPOATE. 
(void *) ps, sizeoi (REG.REHQTE) , 

MF.REPLYVAIT) ; 

> 

/* sa&d msg for aach trans «/ 
lor (i=0; i<aum_tr; i++) 

ps = (REG.REMQTE *) malloc (sizaol (REG.REMOTE) ) ; 
strcpy (ps->sym_nama, trans [i] .naaie) ; 
strcpy (ps->act_najne, trans Ci3 .act .name) ; 
ps->typa = TRAHS.HODE ; 
ps->id = i ; 

il. (trans Ci] .end.owner == HULL) 

■(ps->which = T.BOTH; 

trans[i].id = msgBuildSend (trans [i] .owner , globTid, 

MSG.REGISTER.UPDATE , 

(void *) ps, sizeof (REG.REMOTE) 

HF.REPLYWAIT) ; 

} 

else 

{ps->which - T.STAP.T ; 

trans [i]. id = msgBuildSend (trans [i] . owner, globTid, 

MSG.REGISTER.UPDATE , 

(void *) ps , sizeof (REG.REHOTE) , 

MF.REPLYVAIT) ; 

ps = (REG.REMOTE *) malloc (sizeof (REG.REMOTS)) ; 
strcpy (ps->sym_name, trans [i] .name) ; 
strcpy (ps-> act .name, trans [i] .act.end_naaa) ; 
ps->type = TRASS.HQDE ; 
ps->id = i ; 

ps->which = T.EHD; 

trans [i] . end.id = msgBuildSend (trans Ci] .end.owaer, globTid, 

HSG.REGISTER.UPD ATE , 

(void *) ps, sizeof (REG.REMOTE), 

MF_REPLYVAIT) ; 

}; 

> 

return (OK) ; 

} 


D.3 Xdraw.c — Performs All X-Drawing Actions 

#iaclude <XX1/Xlib.h> 

#include <X11/Xutil.h> 

#include <Xll/Xcs.h.> 

#include <Xll/Xatom.h> 

#include <stdio.h> 


#include <ctos.b> 
#include <btsLib.h> 



#include 

tfinelude 

#icclude 


'•recLib.h" 

••Global.def .h" 

"msg.b** 

#include "Xdraw.p“ 

extirn Display ^display; 
extern Window window; 
extern GC gc; 

extern XFontStruct eact.font; 

extern struct Place *place; 
extem struct Trans *trans; 
extern int nun.pl, nua.tr; 
extern int radius, radius2, diameter; 
extern int tags.on, rates.on, visible.layer; 
/* 

extern struct tape.node «bead; 

extern char *liad_tape_nane() ; 

struct tape.entry 
{int id; 

char *ident_str; 

>; 


struct tape.node 
■Cint id; 

struct tape.node *next; 

}; 

*/ 


/*4t*4i*«*«*««»««*«««««*4i««#«*4>*4t*4i*«*****«*«*« ***************************** 

* draw.whole.net 0 

* This routine clears the display window and redraws the 

* Petri net. Layers are dealt with by the called routines. 

*/ 

void draw.whola.net(void) 

{ 

int i; 

XClearWindow(display, window) ; 

/* 

draw.tapeO ; 

*/ 

/* printlC “Total places: %d\n“,num.pl) ; •/ 

/♦ printlC'Total transitions: XdXn", nua.tr) ; ♦/ 

lor (i= 0 ;i<nua.tr;i++) 

■Cdraw.trans(i) ; 
if (tags.on) 

draw.trans.tag(i) ; 
if (rates.on) 

dras_trans_rate(i) ; 
draw.arcs(i) ; 

if (transii] .firing »= TRUE) 
highlight.trans(i) ; 



lor (i=0;i<nuo_pl;i++) 

-Cdrav_place(i) ; /* this is reduntaat; drav.tokes. redravs the place */ 
drao.tokend) ; 
il (tags^on) 

draH_place.tag(i) ; 

^ • 

XFlushCdisplay) ; 


/**«*«*«***«**********«*«**^**«**«*****«4i**«**<k**#*4i***^********4i**«**M>«* 

* set.tokenO 

* This roatiae sets the aunber ol tokeas ia a place aad 

* redisplays the place. 

*/ 


void set tokea(TID_TYPE Irom, iat data) 

{ 

iat p.aum. aum_tok; 

aum.tok = (datah0xllll0000)>>16: 
p.aus = datakOxllfl; 

place Cp_auin] .carr_tokaa = aua_tok; 
drav_tokea(p_aoffl) ; 

XFlush(display) ; 


/*****♦*♦**♦****♦♦♦♦♦♦♦♦♦♦*★****♦*♦♦****♦♦*♦*♦♦*♦***♦*♦♦♦♦★*♦*♦*♦♦♦**♦♦♦♦* 

* mark.traasO 

* This routiae highlights a traasitioa to iadicate that 

* it hais started to lire. 

*/ 

void mark.traas(TID.TTPE Irom, iat data) 

i 

iat t_num; 


t.aaa = datakOxllll: 
il (•*-+traasCt.au«] .liriag “ 1) 
{highlight .traas (t.anm) ; 

XFlushCdisplay) ; 

>; 

> 


* uamark.traasO 

* This routiae uahighlights a traasitioa to iadicate that 

* a traasitioa has completed liriag. 

*/ 


void uamark.traas (TID.TYPE Irom, iat data) 

{ 

iat t.aian; 


t_num = dataftOxllll; 
il (trams Ct.aum] .liriag !* 0) 

il (— trams Lt_aum] .liriag == 0) /* just reached zero */ 

{highlight _traas(t_num) ; 

XFlush(display) ; 
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>: 

> 

* valid^layerO 

* This routine checks ii any of the indicated layers are 

* currently enabled for display. 

*/ 


int valid.layer(int layer) 
return (visible_layer ft layer); 


* drau_place() 

* This routine draws the indicated place. As a side effect, 

* it erases any tokens that were already drawn. 

*/ 


void draw_place(int i) 

if (valid_layer(placeCil .layer)) 

<draw_type( ERASE) ; 

XFillArcCdisplay, window, gc, place Ci] .x_loc - radius, 

place Ci] .y_loc - radius, 
dianeter, diameter, 0, 360*64); 

draw.type(DRAV) ; 

XOrawArc (display, window, gc, place Ci] .x.loc - radius, 

place Ci] .y_loc - radius, 
diameter, diameter, 0, 360*64); 

/* printf (“Drawing place %d at %d,y.d\n“,i,placeCi] .x_loc,placeCi] .y_loc) ; */ 
}•: 

> 

* draw^tokenO 

* This routine redraws the indicated place to erase the old 

* tokens, then redraws all of the tokens in the place. Up to 

* nine tokens may be drawn, thereafter digits are used. The 

* token size is changed based on the number of tokens in the place. 

*/ 

void draw.token(int i) 

i 

char buff CS] ; 
draw_place(i) ; 

if (valid.layer(placeCi] .layer)) 

•Cswitch(piaceCi] .curr_token) 

{case 0: break; 
case 1; 

draw_l_tok(placeCi] .x_loc, place Ci] .y_loc,L) ; 
break: 


case 2: 

dr aw_l_tok (place Ci] .x.loc - radius/2, place Ci] .y_loc,L) ; 
draw. l^tok (place Ci] .x.loc * radius/2, place Ci] .7.1oc,L) ; 
break; 
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case 3; 

drae_l_tok(placeCi] -x.loc - radius/2, place CiJ .y_loc ♦ radius/2,L); 
drae_l_tok(placeCi] .x.loc ♦ radiua/2, place Ci3 .y_loc + radius/2, L); 
draB_l_tok(place[i] .x^loc, place Cl] . y.loc - radius/2, L); 
break; 


case 4: 

dra»_l_tok(placeCi] .x_loc - radius/2, placed] .y_loc + radius/2, H) 
dras^l.tokCplaceCi] .x.loc radius/2, placed] ^y^loc radius/2, M) 
draw_l_tok(placed] .x_loc - radius/2, placed] -y_loc - radius/2, H) 
drau_l_tok(placed] -x_loc + radius/2, placed] *y.loc - radius/2, M) 
break; 

case 5: 

drau_l_tok(placed] .x_loc - radius/2, placed] .y_loc radius/2, M) 
draB_i_tok(placad] *x_loc + radins/2, placed] .y_loc + radius/2, K) 
drau_l_tok(placed] .x_loc - radius/2, place Ci] .y_loc - radius/2, M) 
drau_i_tok(placed] -x.loc radius/2, place Ci] -y.loc - radius/2, M) 
draw_l_tok(placeCi] .x_loc, placeCi] .y_loc,M) ; 
break ; 

case 6: 

drau_l_tok(place[i] .x_loc - radius/2, place Ci] .y_loc + radius/2, S) 
draw_l_tok (place Ci] -x_loc + radius/2, place Ci] .y_loc + radius/2, S) 
draw_l_tok(placeCi] .x_loc - radius/2, placeCi] .y_loc - radius/2, S) 
drae_l_tok(placeCi] .x_loc + radius/2. place Ci] . y_loc - radius/2. S) 
drau_l_tok(placeCi] .x_loc, place Ci] .y^loc + radius/2,S); 
draw_l_tok(placeCi] .x^loc, place Ci] .y_loc - radius/2, S); 
break; 


case T: 

drau_l_tok(placeCi] .x_loc - radius/2, place Ci] . y_loc + radius/2, S) 
draw_l_tok(placeCi] -x_loc + radius/2, place Ci] • y_loc + radius/2, S) 
drau_l_tok(placeCi] -x_loc - radius/2, place Ci] .y_loc - radius/2, S) 
drauIl.tokCplaceCi] .x_loc * radius/2, place Ci] • y_loc - radius/2, S) 
drav_l_tok(placeCi] -x.loe, place Ci] • y.loc * radius/2, S); 
draw_l_tok(placeCi] -x_loc, place Ci] .y_loc - radius/2, S); 
drau_l_tok(placeCi] -x_loc, placeCi] .y_loc,S) ; 
breedc; 

case 8: 

draw_l_tok(placaCi] .x_loc - radius/2, place Ci] . y_loc + radius/2, S) 
drav_l_tok (place Ci] .x_loc *■ radius/2, place Ci] . y.loc *■ radius/2, S) 
draH_l_tok(placeCi] .x_loc - radius/2, place Ci] • y_loc - radius/2, S) 
drau.l_tok(placeCi] .x_loc + radius/2, place Ci] • y.loc - radius/2, S) 
drae_l_tok(placeCi] .x_loc, placeCi] .y.loc + radius/2, S); 
draw_l_tok(placeCi] .x_loc, placeCi] .y.loc - radius/2, S); 
draw_l_tok(placeCi] .x_loc - radius/2, placeCi] .y.loc.S) ; 
drau_l_tok(placeCi] .x.loc + radius/2. placeCi] .y.loc.S) ; 
break; 

case 9: 

drau_l_tok(placeCi] .x_loc - radius/2, place Ci] . y.loc + radius/2, S) 
drae_i_tok(placeCi] .x_loc + radius/2, placeCi] .y.loc + radius/2, S) 
draB_l_tok(placeCi] .x.loc - radius/2, placeCi] .y.loc - radius/2, S) 
drasr_l.tok(placeCi] .x.loc + raditts/2, placeCi] .y.loc - radius/2, S) 
draw..l_tok(placeCi] .x_loc, placeCi] .y.loc + radius/2, S); 
dra»_l_tok(placeCi] .x.loc, placeCi] .y.loc - radius/2, S); 
draB_l_tok(placeCi] .x.loc - radius/2, placeCi] .y.loc.S) ; 
draB.l_tok(placaCi] .x_loc + radius/2, placeCi] .y.loc,S) ; 
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dr&B_l_%ok(pla.eeCi] .x_loc, plaeaCi] .y.Ioc.S) ; 
break; 


default: sprintf (buff , place Ci] -curr.tokeii) ; 

XOrauStringCdisplay, Bindoe, ge, 

place Ci] -x.loc - XTeztWidth(act_foat , buff. strlea(bufl}}/2, 
placed] .y.loc + (act_lont‘->ascent)/2, 

bull. strlenCbuff)} : 

break; 

>: 

>; 

> 


* draB_l_token() 

* Tbis routine dratrs a single token at the given location and 

* size. 


*/ 


void draB_l_tok(int x,int y, float size) 

■c 

XFillArc (display, window, gc, x - nax((int)(radius*size) ,2)/2, 

y - ni 2 Lx( (int) (radius * size) ,2)/2, 

max((int) (radius*size) ,2) , inax((int) (radius*size) ,2) , 
0, 360*64); 

> 


* draB_place_tag() 

* This routine draws the tag associated with the given place. 
*/ 


void draw.place_tag(int i) 

■C 


> 


if (valid_layer(placeCi] .layer)) 

XDrawString(display, window, gc, place [i] .tag_x, placed] .tag.y, 
place Ci] . name , strlen (place d] . name ) ) ; 


* draw.transO 

* This routine draws the given transition. The line type used 

* indicates the type of transition, and the correct orientation 
« is used as well. 

*/ 


void draw_trans(int i) 

if (valid_layer(transd] .layer)) 

'Cset_line(tran3Ci] .kind) ; 

switch(transd] .orient) 

■Cease 0: XDrawLine (display , window, gc, transd] .x.loc - radius, 

traasCi] .y.loc, transCiJ .x_loc ■*• radius, transCi] .y..loc) ; 
break; 

case 1: XOrawLine(display, window, gc, transCi] .x.loc. 

transCi] .y_loc - radius, trans Ci 1 .i;_loc, 
trans [i] . y.loc radius); 
break; 

case 2: XDrawLine (display, window, gc, 

transd] .x.loc - radius2,transCi] .y.loc - radius2. 
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transCi] .x.loc + radiua2,traasCil . 7 _loc + radius2); 
break; 

deiaulc : 

break; 

>: 

set_liae(DEFAULT): 

>; 

} 

* draa.trans.tagO 

* This routine draes tbe tag associated aitb tbe given transition. 
*/ 


void dray_trans_tag(int 


i) 


ii (valid.layer(trans[i] .layer)) 

XDrauString (display, window, gc, trans Ci] . tag_x 
tr ans Ci] . name , strlen ( trans Li] 


} 


, trans Ci] .tag.y, 
.name)) ; 


/^m**mm*********************************************************^ii********* 

* draw_trans_rate() 

* This routine draws the rate associated with the given transition. 

♦/ 


void draw_trans_rate(int i) 

i 

char builCHAXUKE]; 

il (valid_layer(trans[i] .layer)) 

•Cspr inti (buff , "'/.f " , trans Ci] . f ire_rate) ; 

XDrawString (display, window, gc, trans Ci] *rate_x, trans Ci] .rat e_y, 
buff , strlen (buff ) ) ; 

>: 

> 

* highlight_trans() 

* This routine draws an inverted circle over the given transition, 

* changing it's current display state. 

*/ 


void highlight_trans(int i) 

if (valid_layer(transCi] .layer)) 

{draw_type(IHVERT) ; 

XFillArc(display, window, gc, trans Ci] . x.loc - radius, 
tranij Ci] . y.loc - radius, 
diameter, diameter, 0, 360*64); 
draw_type(DRAif) ; 

J I 

> 


• drac.arcsO 

* This routine draws the input, output and inhibitor arcs for 

♦ the given transition. 

*/ 


void d;;aw_arcs(int i) 
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{ 

stract Arc •arc.a; 

struct Arc_poiat ♦atrc,point.a; 

int X, y; 

arc.a = transCi] .iap_arc; 
shila (arc.a) 

{if Cvalid_layer(arc_a->layar)) 

{x » arc_a->x«start; 
y = arc«a->y_start; 
arc.point.a = 8rc_a->arc_points ; 

Bliil«(arc_point.a) 

{XOraBLinaC display, viadov, gc, x, y. 
arc_poiat_a->x, arc_poiac_a->y) ; 

X s arc_poiat^a->x; 
y » arc_point_a->y; 
arc_point_a - arc_poiat_a->naxt ; 

>; 

XDrawLine (display, window , gc, x, y, arc_a->x_end, arc_a->y_end) ; 
XDrawLine (display, window, gc, arc_a->arrow->xO , arc_a->arrow->yO, 

arc_a->arrow->xl , arc_a->arrow->yl) ; 
XDrawLine (display, window, gc, arc_a->arrow->xO , arc_a->arrow->yO, 

arc_a->arrow->x2, arc«a->arrow->y2) ; 
XDrawLine (display, window, gc, arc_a->arrow->xi , arc_a->arrow->yl, 

arc_a->arrow->x2, arc.a->arrow~>y2) ; 

}; 

arc_a = arc_a->aaxt; 

}; 

arc_a = transCil .out_arc; 
while (arc.a) 

{if (valid_layer(arc_a->layer)) 

{x = arc_a->x_start; 
y = arc.a->y_st 2 a^; 
arc.point.a = arc_a->arc_points ; 
while(arc.point.a) 

{XDrawLine (display, window, gc, x. y, 

ai-c.point_a->x, arcj)oint_a->y) ; 

X = arc_point_a->x; 
y = arc_point_a->y; 
arc.point.a = arc.point_a->next; 

>; 

XDrawLine(display, window, gc, x, y, ^u^c.a->x.end, arc.a->y.end) ; 
XDrawLine(display, window, ge, arc.a->arrow->xO , arc_a->arrow->yO, 

arc.a->arrow->xl, arc.a->arrtw->yl) ; 
XDrawLine(display, window, gc, arc.a->arrow->xO , arc.a->arrow->yO, 

arc.a->arrow->x2, arc.a->arrow->y2) ; 
XDrawLine(display, window, gc, arc.a->airow->xl, arc.a->arrow->yl, 

arc.a->arrow->x2, arc.a“>arrow->y2) ; 

>; 

arc.a = arc.a->aext; 

>; 

arc.a = trans [i] . inh.arc ; 
while (arc.a) 

{if (valid.layer(arc.a->layer)) 

{x = arc.a->x_start; 
y =» arc.a->y.start; 
arc.point.a » arc_a->arc.points; 
whil e ( ar c _pc int . a ) 

{XDrawLine (display, window, gc, x, y. 



arc_poiat_a->3£, arc_point_a->y) ; 

X a arc_point„a->x; 
y « arc_point_a->y; 
arc„point_a = arc_point_a->Bax« : 

>: 

XOrasLinaCdisplay, wiadoo, gc, x, y, arc_a->x_aad, arc,a->y,aad) 
XFillArcCdisplay, »iadoo, gc, arc_a->arrow->xO - radius/3, 

arc_a->arroB->yO - radius/3, 
diaaetar/3, dlametar/3, 0, 360*64): 

>: 

arc_a = arc.a->aext; 

>; 


#deliaa LEFT.EDGE 10 
#deliae TOP.EDGE 10 
#deliaa WIDTH 1024 
«defiae HEIGHT 30 
tfdefiaa HAX.CHAR 10 

/* 

drau.tapa ( ) 

< 

struct tapa.node *tfflp; 
char *aaae; 

iat offset, height, shift, 1=1; 


draw_type(ERASE) ; 

XFillRectaagleCdisplay, uiadou, gc, 
draw_typa(DRAW) ; 


LEFT.EDGE, TOP.EDCE-1, 
WIDTH, HEIGHT); 


XDrawStriag (display, oiadow, gc, LEFT.EDGE, TOP_EDGE+act.loat“>ascaat , 
••TAPE:'*, S); 


tap = head; 

shift = act.foat->aax.bouads .oidth; 

offset = MAX.CHAR*act_foat->aax.bouad3.vidth; 

height = act.foat->aax.botiads.ascaat-*-act.foat->Bax.boaads.desceat: 
Bhil.e(tmp) 

■(naaa = f iad_tape_naBe(tmp->id) ; 

XDravRectaagle (display, viadoo, gc, L£FT.EDGE')-(i)*offset-shift, 

TOP.EDGE-1, offset, height+2); 

lOraaStriag (display, siadow, gc, LEFT_EDGE+(i++)*offset, 

TQP.EDGE+act.f oat->asceat , 
aaae, strlea(aajne)) ; 

tap * tap->next; 

>; 

> 

*/ 


D.4 Xsetup.c — Initializes the Windowing System 

#iaclude <X11/Xlib.h> 

#iacluda <X11/Xutil.h> 

#iaclude <Xll/Xos.h> 

#iaclude <Xll/Xatoa.h> 



tiaelude <stdio.h> 


tiacluda "racLib.h" 
#include "Global^daf .li" 
#includa *’Global_var.p‘* 

#deline BORDER 3 


/a ftinction prototypes — 

void gatGCCUindos ai&dos, GC *50); 
void load.lottt(void) ; 
void sat.fontCint i); 


/m*mmm*mmm***im**mmm*mm*mmm**mmm**m*mmm*m**m*m**m’tt*m*m****m*mm****m**mmm*mm 

* XinitO 

* This routine initializes the X-variables and opens 

* a oindoo. 


*/ 

void XinitCchar •nets.nane, char *argvD, int argc) 

{ 

int X. y; 

unsigned int tridth, height, display .vidth, display_heightj 
char ^vindov.name = nets.name; 
char *icon.name = nets.name; 

XSizeHints size.hints; 

XUHHints va.hints; 

XClassHint class.hints; 

XTextProperty 9indo«maae,iconname; 
char *program_name = "Display”; 


/* connect to X server */ 

ii ((display = XOpenDisplay(display_naoe)) == lULL) 

■(recInlo(globTid,"NeC ^s cannot open display */.s\n", nets.name, 

XOisplayHaae(display_name) } ; 

exit(-l) ; 

>; 


/* get screen information */ 
screen.num 3 OefaultScreen(display) ; 
display .vidth ~ 0 isplay Width (display , screen.num); 
display Jieight 3 OisplayHeight (display, screen.num} ; 

/• set desired window settings */ 

X 3 0 ; 
y = 0 ; 

width 3 display.width/ 2 ; 
height 3 display .height/2; 

/* create the window */ 

window = (Window *)XCraataSinplaWiadow(display, 

RootUindow(display^sereen.num) , y, 

width, height, BORDER, BlackPixel (display, screen.num), 

VhitaPizel(display , screen.num) ) ; 

/* provide hints for the window manager */ 
size.hints.flags = PPosition I PSize; 

/* setup the window and icon name */ 


a (XStringListToTextProparty(tQiado?.&aaa, 1, ftwindoBnana) •• 0} 

<lpriatl(stdarr,"HaC y.s f&ilad structura allocation lor aindo«naffla.\xi“» 

nats.nane) ; 

axit(-l): 

}; 

il (XStringListToTaxtPropartyCticon.naaa, 1, fticonaama) o) 

{lprintl(stdarr,"llat %s lailad structura allocation lor iconnana An" . 

aats.name) ; 

axit(-l); 

>: 


«n_hints.initiad.stata = VormalStata; 

TO_hints . input » True; 
am.hints.llags = StataHint I Znputfiint; 

class.hints .ras_nana 3 prograB_naBa ; 
class.hints.ras.class 3 prograa_nana ; 

XSatUHPropertiasCdisplay, (int)oindov, ftuindoimaiae, fticonname^argv.argc, 
ftsiza.hints, ftnm.hints, Jtclass.hints) ; 

/♦ sat desirad event types */ 

XSelact Input (display, (int) aindou, ExposureHash I KayPressHask 1 

ButtonPrassNiisk ( StructuraNotilyHask) ; 


/♦ load lonts */ 
load_lonts() ; 

/• create GC */ 
gatGC(aindoa, tgc); 

/♦ display the windoa */ 

XHapVindov (display, (int) aindoa); 

XFlash(display) ; ■ 

> 

* getGCO 

* This routine creates the graphics context (GC) and 
m sets up the dalault parameters. 

*/ 

void gatGC(Windoa vindoa, GC *gc) 

i 

unsigned long valuemask 3 O; 

ZGCValues values; 
int line.style s LineSol'd; 
int cap.styla 3 CapRoond; 
int join.style » JoinRoond; 
int dash.ollsat = 0; 

*gc 3 xCreateGC(display, vindov, valuemask, Rvalues); 
set_lont(l) : 

XSetFont (display , *gc, act.lont->lid) ; 

XSetForegroundCdispIay, *gc, BlackPixal(display,screan.nuA)) ; 
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XSetLineAttributes(display, *gc, lina_ 7 idth, lina^scyle, 

cap.styla, join.styla) ; 

> 



* sat_Iina() 

* This routlaa changas tha lina typa dapanding upon 

* tba typa ot transition to ba dram. 

*/ 

void set.lina(int i) 

< 

switch(i) 

{casa ZMH: XSatLinaAttributas(dispIay, gc, lina_vidth.o3/2, LinaSolid, 

CapButt, JoinRoond): 

braak; 

case DET: XSatLineAttributas (display, ge, radius/2, LinaSolid, 

CapButt, JoinRound); 

braak; 

casa EXP; XSatLineAttributas (display , gc, radius/2, LinaSolid, 
CapButt, JoinRound); 

break; 

default: XSatLineAttributas (display, gc, line.sidth, LinaSolid, 

CapButt, JoinRound); 

>; 

> 

/**4i«*«4i**««**a4iW*«»*****««**««a****4i«*««*«**««**«****«>*«*4i**««*«««»««««*« 

* load.fontsO 

* This routine loads all of the fonts that the display 

* needs to shoe tokens, tags, etc. 

*/ 

void load_fonts() 

{ 

if (! (font Co] » XLoadQuaryFont(display,"5x8"))) 

■Cfprintf(stderr, “Cannot load SxC f ont\n“) ; 

axit(-l); 

>: 

if (!(fontCl] * XLoadQuar 7 Font(display,” 6 xlO“))) 

<fprintf(stderr, “Cannot load 6x10 font\n"}; 

exit(-i); 

}; 

if (!(font[2] * XLoadQuaryFont(display,"8xl3“))) 

■{fprintf( 3 tdarr, “Cannot load 8x13 font\n“); 

axit('l); 

>; 

if (!(fontC3] = XLoadqueryFont(di 3 play,"SxlS'’))) 

{fprintf(stderr, “Cannot load 9x15 font\n“); 

axit(-l): 

>; 

> 

/^mtt*m***************i*»*****0*******»**************m*********mm***mv*»»*** 

* set.fontO 

* This routine changes the current font in use. 

*/ 
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void set_font(int i) 

/ 

% 

act.font a fontCi]; 

XS«tFont(display, gc, act.foat->fid) ; 


• dray.typeO 

* This routine changes the draving node. 

*/ 

void drao.typeCint mode) 
syitch(ttode) 

■Ccaise ERASE:. XSetForeground(display, gc, Whit ePixel (display, screen.num) } ; 
XSetFunctionCdisplay, gc, GXcopy) ; 
break; 

case DRAW: XSetForeground (display, gc, BlackPixel(display,screen_nua)}; 

XSetFunction(display, gc, GXcopy); 
break; 

case INVERT; /• XSetForeground(display,gc, WhitePixel(display,screen_num)) ; 
XSetFunction(display, gc, GXxor) ; */ 

XSetFunction(display. gc, GXinvert); 
break; 

default: break; 

>: 

> 


D.5 manip^net.c — Performs Scaling and Shifting of Display 

#include <X11/Xlib.h> 

#include <X11/Xutil.h> 

#include <Xll/Xos.h> 

#include <Xll/Xaton.h> 

#inclttde <stdio.h> 

#include <aath.h> 

•include "Global.deX .h" 

•include “ Global. var.p" 


nodily.end.po tnt (ar c , X , y ) 
struct Arc *arc; 
iat x,y; 

i 

int dx, dy; 
double angle; 

dx * X - arc->x.end; 
dy = y - arc->y_end; 

il (dx 0) 

{il (dy >0) 

arc->y_end ♦= radius; 

else 

arc->y.end -« radius; 
return; 

>; 
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if (dy aa 0) 

■Cif (dx >0) 

arc->x_end radius; 

else 

arc->x_«nc‘. -a radius; 
ratum; 

>: 


angle a atan((doubla)dy/dx) ; 
if (dx > 0) 

{ 2 urc->x_end *» radiusacos (angle) ; 
arc->y_end radiua*sin(angle) ; 

else 

•Carc->x_end -= radius «cos (angle } ; 
arc->y_end -a radius *sin( angle); 


> 

modify_arrow(arc,x,y) 
struct Arc *arc; 

^ int x.y; 

int dx, dy, xO, yO; 
double angle; 
stmct Arrowhead *arr; 

if (arc->arrow) 

arr = arc->arrow; 
else 

“ (struct Arrowhead *)malloc(sx 2 eof (struct Arrowhead))* 
»rc->arrow = arr; ’ 


if (arc->type a= OUTARC) 
{xO a arc->x_end; 

^yO a arc-> 7 _end; 

else 

{xO * arc->x_start; 
yO a axc->y_start; 


ar7.*->x0 a xO; 
arr->yO a yO; 

dx a X - xO; 

dy a y _ yO; 

if (dx aa 0) 

•Cif (dy >0) 

angle a -M_PI/2; 
else 

angle = M.PI/2; 

else 

{if (dy as 0) 
angle * 0.0; 

else 

angle a atan((double)dy/dx) ; 


ii (dx > 0) 

■Caxr->xl = xO 
arr->yl = yO 
arr->x2 = xO 
9XT~>'f2 - yO 

> 

else 

•Carr->xl = xO 
arr->yl. = yO 
arr->x2 = xO 
arr->y2 = yO 
}; 


* radius*cos(angie+AMG) 
radius«sin(angle-«-ANG) 

* radius«cos(angle-ANG) 
+ radius*sis.(angle-urG) 


- radius^cosCangle+AHG ) ; 

- raditts*sin(angle-*-AKG) : 

- radius*cos (angle- AHG) ; 

- radius*sin(angle-AHG) : 


} 

modi! y_ en.d_ c ire 1 e ( arc ) 
struct Arc *arc; 

< 

int X, y: 

struct Arronhead *arr; 
arr = arc->arroo; 

arr->xO = (2*arr->x0 + arr->xl + arr->x2)/4; 
airr->yO = (2*arr->y0 + arr->yl + aLrr->y2)/4; 

} 

r escale_net ( scale , offset _x,olfs et_y ) 
float scale, offset_x, offset_y; 

•C 

int i, X. y. xl, yl; 

struct Arc *arc_a, *arc_b; 

struct Arc_point *arc_point_a, *arc_point_b; 

diameter = (int)DIAHETEa*scale; 

radius = dianeter/2; 

radius2 = (int)(radius/1.414); 

for (i=0;i<num_nip;i++) 

•Cmp2Lrti3 .tag_x = X_IH_TO_PIX(mpar[i] .tag_x_in) ; 

mparCi] .tag_y = Y_IN_TO_PIX(aparCi] .tag_y_in) ; 

}; 


lor (i=0;i<num_rp;i++) 

•C^ar Ci] . tag_x = X_IH_TO_PII(rparCi] .tag_x_ia) ; 
rparEi] .tag_y = Y_IH_TO_PIX(rparCi] .tag_y_in) ; 


lor (i=0;i<nua_pl;i++) 

{place Ci] -x_loc = X_IH_TO_PIX(placo[i] .x_loc_in) ; 
place [i] .y_loc = Y_IH,TQ_PIX (place Ci] .y_loc_in) ; 
place Ci] .tag.x = X_IN_TO_PIX(placeCi] .tag_x_in) ; 
place Ci] .tag_y = Y_IH_TO_PIX(place[i] .tag_y_in) ; 


lor (i=0;i<num_tr;i++) 

•CtransCi] .x.loc = X_IH_TO_PIX(transCi] .x_loc_in) ; 
transCi] .y_loc = Y_IH_TO_PIX(transCi] .y_loc_in) ; 
trans [i] ,tag_x = X_IH_TO_PIX(trans[i] .tag_x_in) ; 
transCi] .tag.y = Y_IH_TO«PIX(traa,sCi] .tag.y_in) ; 
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transCi] .rat«.x a X_IS.T0„PIX(tr'ansCi3-rat*_x.in); 
traasCi] .rat «_7 a Y.II_TO_PIX(traasCi] .ratejr_in) ; 

arc.a ~ transCi] • iQp.arc; 

Bhila(are_a) 

{x ® arc_a->x_atarc = transCi] .x_loc: 
y = arc_a->y_start = transCi] .y_loc; 
arc_a->x_and = placeCarc_a->place] .x_locr 
arc_a->y_and = placa[arc_a->place] .y_loc; 
iX (arc_poiat«a ® arc.a->arc_points) 

{xl a X_IM_TO_PIX(arc_poiat_a->x_in ) ; 
yl ~ Y_IM.TO_PIX(arc^point_a->y^in) ; 

} 

alsa 

{xl = arc_a->x_en.d; 
yl = arc_a->y«end; 

>: 

Bliile(arc_point_a) 

{x = arc_point_a->x ® X_IM_TO_PIX(arc_point_a->x_iii) ; 
y = arc_poiat_a->y = Y_IN_TO_PIX(arc_point_a->y_ia) , 
arc_poiat_a = arc .point _a->aext; 

>; 

modify_ead_poiat(arc_a,x,y) ; 

Bodify_arroB(arc.a,xl,yl) ; 
arc_a = arc_a->aext ; 

>: 

arc.a = transCi] .out.arc; 
vh.ile(arc_a) 

{x = arc_a->i_start = transCi] .x.loc; 
y = arc_a->y_start = traas [i] . y.loc ; 
arc.a->x_ead - placaCarc.aOpiaca] .x_loc; 
arc_a->y.and = placeCarc_a->place] .y_loc; 
arc.point.a = arc_a->etf’c_points; 
vhila ( arc _po iat _a) 

{x = arc_point_a->x = X.IH_TO_PIX(arc_point_a->x_ia) ; 
y = arc_point_a->y = Y_I5_T0_PIX(arc.point_a->y_in.) ; 
arc_point.a = arc_poia,t.a->aext; 

J » 

modily_ead_point(arc.a,x ,y) ; 

Biodify_arroB(arc_a,x,y) ; 
arc.a ® arc_a->aext; 

>: 

arc.a * transCi] .inh.are; 

Bh.ile(arc.a) 

{x ® arc_a->x.starc = transCi] .x.loc; 
y = arc_a->y_start = tranaCi] .y_loc; 
arc.a->x_and ® placaCarc_a->placa] ,x_loc; 
arc.a->y_aad = placaCarc_a->place] .y.loc; 
iX (arc.poiat.a = arc_a->arc_poiats) 

{xl = I_IH_TO_PIX(arc_point_a->x_ia) ; 
yl a Y_Ilf.TO_PIX(arc.poiat_a->y.in) ; 

> 

else 

{xl = arc_a->x.and ; 
yl a arc.a->y.ead; 

>; 

Bhila ( arc _po iat _a ) 

{x a arc_point_a->x - X_IH.TO_PIX(arc_point_a->x_in) ; 
y a arc_poiat.a->y = Y.IH.TO_PIX(arc_poiat.a->y_ia) ; 
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arc_point.a « arc.point.a->ziext; 

>; 

modily_«ad_point(axc.a,x,jr) ; 
Bodiiy_arroB(axc_a,xl,yl) ; 
modify. end_circle(arc_a) ; 
arc.a = arc_a->naxt; 

>; 

>: 

line.sidth = 0; 
if (diametar < 20) 
sat.font(O) : 
alsa 

if (diamater < 26) 
sat_foat(l) ; 
alsa 

if (diametar < 35) 

-Csat_font(2) ; 
line.sidtti = 2; 

} 

alsa 

•Cset_font(3) ; 
line.ffidtli = 3; 

> 

} 


D.6 monitor.c — Processes X- Window Events 

#inclade <X11/Xlib.li> 

#include <X11/Xatil.li> 

#includa <Xll/Xos.h> 

#inclade <Xll/Xatom.h> 

#inclade <XllAeysym.h> 

^include <stdio.h> 

#includa <ctos.h> 

tiacluda “Global.daf . h" 

#iacluda "Global.var.p" 

#i&c'i.ude "msg.b" 

axtam Display *display: 
axtaxa radius ; 

void go_moxiitor() 

iat id, dist; 

X£vaat raport; 

XKayEvaat *rap_ptr; 
cbJff buff CS] ; 
cbar buf [10] ; 

KaySym kay; 
iat f; 

MSG.rfPE msg; 

iat shift_hor=0, shift.var=0, siza.ctaag=0, rascala = FALSE; 
ahila (1) { 

XHaxtEvaat (display, traport); 
switch (raport. type) { 
casa Exposa: 
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/* ixb1«ss this is the last contiguous expose, 

* don't dratr the windoa */ 
il (report. xezpose. count 0) 

break; 

BSgBuildSend (globTid, globTid, NSG,DaAV.UHQLE.lIET, 
BULL. MS_H0HE, MF.STAHDARD) ; 

break; 

case ButtonPress: 

rep_ptr » (struct IKeyEvent *)kreport; 
near.trans (rep_ptr->x ,rep_ptr->y , kid , kdis t ) ; 
it (dist <3 radius) 

msgBuildSend(globTid, globTid, MSC_SELECT_TRA»S . 
EVCODE.BUTTQN(report . xbutton . button , id) , 

MS.IOBE, KF.STANDARD) ; 

near_place(r ep_ptr->x ,rep.ptr->y , kid ,kdist ) ; 
if (dist <= radius) 

BSgBuildSend (globTid, globTid, MSG.SELECT.PLACE, 
EilCODE.EUTTQIf(report .xbutton. button, id) , 

MS.IOBE, HF.STAIfDARD) ; 
break; 

case Keypress: 

t 3 XLookupString(kreport , buif, 5, kkey, 0); 
suitch(key) 

•(case XK.t: 
case XK.T; 

BsgBuildSend(globTid, globTid, 
HSG.TOGGLE.TAGS, 

HULL, MS.H0NE, KF.STAHDAM)) ; 

break; 
case XK.s: 

il (globTid != playTid) 

(recInio(globT id, "Sending local mode: */,d\n", 

SIHGLE_STEP) ; 

msgBuild(kmsg, globTid, globTid, MSG_SET_MQDE , 
(void *)SIHGLE_STEP. MS_H01fE, MF.STAHDAIID) ; 
BsgSend(kmsg) ; 

msgBuild(kmsg, playTid .globTid, HSG_SET_M0DE, 
(void ♦)SIHGLE.STEP, HS.NONE, HF.STAHDAHD) ; 
BSgSend(ftmsg) ; 

^ * 

break; 
case XK.S: 

reclnio(globTid, "Sending global Bode: %d\n‘‘, 

SIHGLE.STEP) ; 

msgfluild(toasg, globTid, globTid, HSG.SET.MODE , 
(void *)SIKGLE_STEP, MS.HQME, MF_STANDAilD) ; 
BsgSend(kBsg) ; 

BsgBroadcast(kBsg. MB.APPLICATIQH) ; 
break; 
ease XK.c: 

if (globTid !* playTid) 

{recInfo(globTid, “Sending local mode: 7.d\n", 

CQNTIHUOUS) ; 

BSgBuild(kBsg, globTid, globTid, MSG.SET.MQDE, 
(void •)COITIHUauS, MS.HQHE, HF.STAHDAHD); 
BsgSend(kBSg) ; 

BSgBuild(kmsg, playTid, globTid, MSG.SET.HQDE, 
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(void *)CQ!mNUQt;S. MS.NQHE, MF.STANDARD) ; 
0 sgSend(tas£} ; 


caso XK_C: 

recZaloCglobTid/'Sendiag Global mode: Xd\n", 

CONTIirUQUS) ; 

msgfluild(4msg, globTid, globTid, MSG.SET_MODE, 
(void •)COm]TOOUS. KS.H05E, MF.STATOARD) ; 
fflsgSend(Aasg) : 

msgBroadcast(A 0 sg. MB.APPLXCATZatf}; 
break; 
case XK.r: 
case XK.R: 

fflSgBuildSend (globTid. globTid, 
MSG,DRAy.WHQLE.HET, HULL, 

MS .HONE, MF.STAHDARD) ; 
break; 
case XK.Left: 

fflsgBuildSend(globTid, globTid. 
KSG.SH1FT.DISPLAY, 

(void *)LEFT, MS.HONE, MF.STAMDARD) ; 
sbiit^hor = LE^; 
rescale = TRUE; 
break; 

case XX.Right: 

msgBuildS end (globTid, globTid, 
MSG.SHIFT.DISPLAY, 

(void ♦)R1GHT, MS.IQHE, MF_STANDARD) ; 
shift_hor 3 RIGHT; 
rescale = TRUE; 
break; 

case XX.Up: 

osgBuildSend(globTid, globTid. 
MSG.SHIFT.DISPUY, 

(void *)UP, MS_H0NE, MF.STAHDARO) ; 
sbift.ver = UP; 
rescale » TRUE; 
break; 

case ZK.Dovn: 

BsgBnildSend(globTid, globTid, 
MSG.SHIFT.DISPUY, 

(void *)D0HH, MS.HOHE, MF.STAHDARD) ; 
skilt.ver ^ OOWH; 
rescale = TRUE; 
breads; 

case XX. comma: 
ease XK.less: 

msgBuildS end (globTid, globTid, 
MSG.CHANGE.SCALE, 

(void *)DEC, MS.NONE, MF.STAHDARD) ; 
size.cbng = DEC; 
rescale = TRUE; 
break; 


case XX.period: 
case XK.greater: 
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msgBnildSttndCglobTid. globTid, 
MSG.CHAffGE.SCALE. 

(void •)IMC, HS.HOHE, MF,STAHDARD) ; 
size.etmg a igc; 
rescalo = TRUE; 
braak; 

case XX.q; 
case XK^Q: 

recProopt (globTid, buT, 

"Conlizm Application Exit (y/n): “): 
ii ((bufCO] »y')l KbulCO] »= *Y*)) 
msgApplicatio&Exit (globTid) ; 
break; 


case 

.IK.O 

case 

XK.l 

case 

XK.2 

case 

XK.3 

case 

XK.4 

case 

iK.S 

case 

XK.6 

case 

XK.7 

case 

XK.8 

case 

XX.9 


visible.layer l«(key-XK_0) ; 
msgBtildSend(globTid, globTid, MSG.VISIBLE, 
(void ♦)visible_layer, MS.IOHE, MF_STAaDARD) ; 
break; 

>; 

default : 

break; 

} /♦ end switch. •/ 
if (rescale) 

ioffset_z += (float)BOiiI.SHirr(shift_hor) ; 
offset.y += (float )VER7_SHIFT(shift_ver) ; 
scale += (float) (size. chng*SCALE_FACTOR) ; 
if (scale <» 0.0) 
scale a 0.1; 

rescale.net (scaJ.e, offset.x, offset.j); 

shift_hor ~ shift.vez a size.chng = 0; 

>; 


} /* end while */ 

> 

D.7 Xinter.c — User Selection of Places and Transitions 

#inelude <stdio.h> 

#inclade <math.h> 

#include “Clobal.def .h” 


extern struct Trans *trans; 
extern struct Place eplace; 
extern int noa.tr; 


«xtem int aun_pl; 


* near.transO 

* This roatin« locates the transition nsarsst the point x.y. The 

* variables id and dist are modified to reflect the id number 

* of the transition and the distance to it in pixels. 

*/ 

near_trans(x,y,id,dist) 
int z. 7 ,*id,*dist; 

{ 

int min. 1; 


min a (transCO] .x_loc-x)*(trans[0] .x_loc-x) + 

(transCO] .y_loc“y)*(transC0] .y_loc~y) ; 


♦id a 0; 


for (i=l;i<num«tr;i++) 

{♦dist a (transCi] .x_loc-x)*(tr 2 uisCi] .x_loc-x) + 

(transCi] .y_loc-y)a(trana[i] .y_loc-*y); 

if (♦dist < min) 

{min = ♦dist; 

♦id = i; 

>; 

}; 

♦dist a (int)sqrt((doable}min); 


♦ near.placeO 

♦ This routine locates the place nearest the point x.y. The 
.♦ variables id and dist are modified to reflect the id number 

♦ of the place and the distance to it in pixels. 

♦/ 

near .plac o ( x , y , id , dist ) 
int x.y,eid.*dist; 

{ 

int min, i; 


min a (placeCO] .x_loc-x)v(placeCO] .x_loc-x) + 

(placeCO] .y_loc-y)* (place [0] .y_loc-y) ; 


♦id a 0; 


lor (i=l;i<num_pl;i++) 

{♦dist a (placeCi] .x_loc-x)*(placeCi] .x.loc-x) 

(place Ci] .y_loc-y)a (place CiJ .y_loc~y) ; 

if (♦dist < min) 

{min a *dist; 

♦id a i; 

>; 

}; 

♦dist a (int)sqrt((double)min) ; 

} 



